Re: Specify Xcode linker version / compatibility
Re: Specify Xcode linker version / compatibility
- Subject: Re: Specify Xcode linker version / compatibility
- From: Dan Korn <email@hidden>
- Date: Thu, 5 Nov 2009 19:41:31 -0600
On Nov 4, 2009, at 8:29 PM, Dan Korn wrote:
I can specify the compiler version with the GCC_VERSION setting,
but how can I tell Xcode to use the linker that corresponds to that
version of the compiler? Alternatively, how can I get Xcode 3.2 to
link the same way that Xcode 2.5 does, with code compiled by GCC
4.0, for the same project?
I'd like to be able to do all my development on Snow Leopard, but
I'm stuck doing all my builds on Leopard until I figure this out.
Any ideas on how I can make the executable link the same way in
Xcode 3.2 as it did in 2.5?
On Nov 4, 2009, at 11:40 PM, Chris Espinosa wrote:
Xcode uses the compiler to drive the linker, but there is generally
only one linker per toolset. Leaping from Xcode 2.5 across 3 major
versions and 4 minor versions is quite a change, especially as the
linker in Snow Leopard is full 64-bit.
But the linker preserves backwards compatibility when you're
targeting older operating systems. If you set your Deployment
Target to 10.5 and link against the Mac OS X 10.5 SDK, you should
get an executable that is structurally similar to the executable
built by Xcode 2.5 on Leopard. It won't be bytewise identical but it
will be much closer than a binary built to run on 10.6.
Chris
Thanks. I appreciate your response, and that's all good information,
but it's not enough to solve the problem.
I am specifying both the Base SDK and the Deployment Target, actually
both to the 10.4(u) SDK, in all my projects, since we still need to
support Tiger.
We (my team) have been fairly happily using Xcode 2.5 for quite a
while now, but with the advent of Snow Leopard, we needed a way to be
able to build and debug under that OS, which (as you know) requires
Xcode 3.2. But, I can't seem to reliably do this, since the code I
build on Snow Leopard doesn't run the same way as the code I build on
older operating systems. Even if we institute a policy that we can
only do production builds on Leopard, we still can't debug on Snow
Leopard because we can't build code that works properly on Snow Leopard.
So, when you say that "the linker preserves backwards compatibility
when you're targeting older operating systems," what exactly do you
mean? Does that only apply to Leopard (10.5)?
It's not that I don't believe you, but here I am with the same project
files, same sources, same SDKs, and it's giving me different output,
which behaves differently at runtime.
No matter what settings I change, the Xcode 3.2 linker seems to want
to make much smaller executables than under Xcode 2.5, which is a good
thing in theory, but something that it's stripping out is breaking the
program. I don't know exactly what specific difference in the build
is the source of the problem; I've been trying to debug, but as I
said, I can't do that reliably.
The problem seems to be subtle and unique to this particular project,
which builds a plug-in, which in turns links against dylibs in its own
bundle. But I can't exactly attach my entire multi-project source
code tree to a bug report, or to a post to this list.
So again, how can I get Xcode 3.2 to generate linked binaries that
work the same way as they do when I build using Xcode 2.5? I don't
need it to be "bytewise identical," or even "structurally similar,"
but I do need it to work.
Thanks,
Dan
P.S. Just for fun, I did try setting the Base SDK to 10.5, but I got
this linker error:
ld: file not found: /System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/
Versions/A/WebServicesCore
Even though there's no reference to WebServicesCore anywhere else in
the entire build transcript. But that's a separate issue. At any
rate, it seems like there should be a way to make this work with the
10.4 SDK. (Just for even more fun, if I set the Deployment Target to
10.5 while leaving the Base SDK at 10.4, the link succeeds, but I have
the same runtime problems.)
_______________________________________________
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