On Wed, Jun 11, 2008 at 12:12 PM, Charles Srstka
<[EMAIL PROTECTED]> wrote:
> 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?

Yes, in fact it does matter. If Xcode resolves the symlink and stores
a direct reference to libz1.dylib, then it will continue to use that
even if you later move to a newer SDK with a newer version of libz.
When ld resolves the symlink, it does so each time you build, so
you'll always get the correct version for the SDK you're using.

>> 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.

My solution for that is simple. I don't want to write my code twice,
so if I want to support 10.3, I write it using methods that are
available on that version. And if I need to use methods that *aren't*
available on 10.3 - or an entirely new framework, such as Core Data -
I don't even try to support 10.3.

> 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.

Or, you could simply avoid the methods that aren't available on your
target OS. :-)

sherm--

-- 
Cocoa programming in Perl: http://camelbones.sourceforge.net
_______________________________________________

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]

Reply via email to