Re: Linking woes
Re: Linking woes
- Subject: Re: Linking woes
- From: Eric Albert <email@hidden>
- Date: Wed, 29 Nov 2006 21:28:50 -0800
On Nov 29, 2006, at 10:26 AM, Brad Oliver wrote:
I've run into a bit of a stumper with the linker in Xcode 2.4.1
Here's the background: I'm overriding wprintf, vfwprintf and
related functions with my own implementations based on Darwin
source. So I've got a project that creates a static library (.a)
and a BSD command-line app that exercises the test cases.
When I link this library in my BSD command-line app, all works fine
and it passes the 2-line test harness I've set up to demonstrate
that it's being used.
When I link the library into the app I really need it for, I get a
linker error: "multiple definitions of symbol _vfwprintf". This
larger app links to various frameworks like Carbon and System and
is a large packaged app. I'm using the latest 10.4u SDK, as far as
I know.
I've set the build settings in my simple command-line app to match
my bigger app as closely as possible and still see the discrepancy.
The major difference between the 2, that I can see, is that the
bigger app also links against a bunch of other intermediate static
libraries that are generated during the build. These other static
libraries do use the wprintf routines I hope to override, but do
not directly link to the .a file I've created (doing so does not
eliminate the link error).
Key settings: DWARF is used, dead-code stripping is on (along with -
gfull), only link essential symbols is on, it's using the dynamic
version of the C++ library, "Link with Standard Libraries" is on,
single-object prelink is off, stripping is off, PIC-dependent code
is on (-mdynamic-no-pic), Fix&Continue and ZeroLink are off,
symbols hidden by default is on. There is a prefix header and it's
precompiled (another difference between builds).
The other wrinkle is that this larger app contains routines to
override fopen and a few others, and I don't get multiply-defined
link errors for those (and they work as expected). The difference
there being that these others are not being linked into the final
app via a static .a library - they're in a source module that's
directly in the app target.
My best guess here is that this is a link order issue. Try ensuring
that the static libraries are last on your link line aside from
source files -- after all of the frameworks and dynamic libraries
you're linking against. If I'm thinking about this correctly (and
I'm probably not), if your static libraries get linked in before the
frameworks, the frameworks' undefined references don't get resolved
against the static libraries. Putting the static libraries after the
frameworks will get those references resolved.
Or I have this completely backwards and they need to be first. :)
Hope this helps,
Eric
_______________________________________________
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
| References: | |
| | >Linking woes (From: Brad Oliver <email@hidden>) |