On Jun 11, 2008, at 10:49 AM, Sherm Pendley wrote:
Check the libraries with otool. Runtime dependencies come from the
install_name of the linked library, not from the filename that was
passed to the linker.
In which case it shouldn't matter at all whether Xcode is resolving
the symlink or not, no?
when building against the 10.4u SDK (if I were building against the
10.5
SDK, I'm sure it would link against libcurl.4.dylib and not work
with Tiger
anymore).
That's why (well - one reason why) you need to use the SDK that
corresponds to the oldest version of Mac OS X on which your app will
run. If you use a newer SDK, the symlink will resolve differently and
you'll end up linking to a library that isn't available on older OS
versions.
The problem comes up when you want to use a method that's only
available on 10.4 and higher (checking the OS version first so that
you can gracefully degrade on 10.3.x), or when Apple decides to
deprecate a whole bunch of methods in 10.4 and replace them with
methods that are only available starting in 10.4, in which case you
have to use the 10.4 methods inside OS checks to avoid using
deprecated methods on the current OS. In either of these cases, you
have to link against the 10.4u framework (or in my case, my hacked
copy of it) in order to avoid getting a whole bunch of warnings.
Well, I suppose you could ugly the code up with a lot of
performSelector: and NSInvocation and such, but I'd rather not do that.
To make my app launch on Panther, I've been using a custom SDK I
made which
is identical to the 10.4u SDK except with libcurl.2.dylib from
Panther in it
when compiling for PPC (compiling for Intel uses the regular 10.4u
SDK, of
course). Otherwise, it doesn't launch on Panther.
It's pretty frustrating, so if there's a way to be able to use the
GUI to
add libraries without having to work around it in this way, I'd
love to know
how to do it.
From Apple's "Cross-Development Programming Guide":
"To do so, add new entries for the SDKROOT_ppc and SDKROOT_i386 build
settings to the table in the Build pane of the target or project
inspector. Set SDKROOT_ppc to point to the Mac OS X 10.3.9 SDK and set
SDKROOT_i386 to point to the Mac OS X 10.4 Universal SDK. You can type
the full path to each SDK or simply drag the SDK folder from the
Finder to the Value column."
Yeah, I kind of mentioned that's what I've been doing. SDKROOT_ppc is
my hacked SDK with the old libcurl in it, and SDKROOT_i386 is the
normal 10.4u one.
Charles
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
