Re: Linker fails to link in static library SOLVED
Re: Linker fails to link in static library SOLVED
- Subject: Re: Linker fails to link in static library SOLVED
- From: Mark Wagner <email@hidden>
- Date: Mon, 17 Jan 2011 16:49:51 -0800
On Mon, Jan 17, 2011 at 15:49, Philip White <email@hidden> wrote:
>
> On Jan 17, 2011, at 5:00 PM, Xochitl Lunde wrote:
>
> I add the resulting library to another
>> project, make sure it is listed in the "Link Binary with Libraries"
>> phase for the appropriate target, and try to build, but the linker
>> gives me an error for every reference to a function from the library.
>>
> What happens if you add the library path to "Library Search Paths" and add
> "-lyourlib" to "Other Linker Flags" field? Will it link then? You could
> also add the full path to "Other Linker Flags" field: "$path/path/yourlib.a"
> (This should be approx. the same thing as adding it to the "Link Binary with
> Libraries" field, but just for the sake of determining if something else
> will work you can try it.)
>
> Could your dependencies be out of order?
>
> Could you be building this new library only for 1 architecture, but not the
> first architecture that tries to link? Should be able to run $> file
> yourlib.a and see what architectures it built for and whether or not Xcode
> REALLY built a static library, or if it built a dynamic library with a .a
> file extension. In your library info it should say "Mach-O Type" = Static
> Library (I think).
>
>
> Hi,
> Thanks for all of the responses I got for this, on and off-list. I have to
> sheepishly admit that it was a problem of an omitted "extern "C"{" in the
> library header file. I've never before used C++ (I'm an obj-c programmer,
> like most of you guys, I imagine). The library was laid out as C, but I was
> calling it from some C++ source files. Sorry for wasting your time! In my
> defense, the linker error was not terribly helpful, but then, I don't know
> enough about C++ to know if the linker could generate a more helpful
> message!
The problem arises *because* the linker is trying to generate a more
helpful error message, and is converting mangled C++ names into
readable names. If the "could not resolve" messages printed the
actual symbols the linker was looking for (such as
__ZN8funcPlot7SetGridEP4Grid), it would be much more obvious what's
going on.
--
Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden