libz.dylib versus libz.1.2.3.dylib versus libz.1.2.5.dylib

I asked this in a comment but this seems like an issue that deserves its own question.

I have a project that's shared between three different installations of XCode and two different installations of the iOS SDK. At the moment unifying the developers involved is not an option.

When I installed the iOS 5 Beta and XCode 4.2 libz.1.2.3.dylib was nowhere to be found. I discovered that linking against libz.1.2.5.dylib handled this but this was not compatible with the other active installations of XCode and the iOS SDK.

I researched this online and discovere开发者_开发问答d the above suggestion and this suggestion. The former doesn't work for me, and the latter makes me nervous.

So what's the difference between libz.dylib, libz.1.2.3.dylib and libz.1.2.5.dylib and can I safely link to the first across all installations of XCode and the iOS SDK?

---

The OS often includes many versions of dynamic libraries. These are used by different programs depending on which library they were compiled against at their compile time, but when you compile you want to link against the version that correspond to the installed headers which you are including/importing into your source code.

The libz.dylib will be a link to the same version that your installed headers use.

Say you have 2 versions libXYZ.1.dylib and libXYZ.2.dylib, libXYZ.dylib is a link to libXYZ.2.dylib and libXYZ.1.dylib is a legacy lib that is also available in the OS for apps compiled and distributed before libXYZ.2.dylib was released. The libXYZ.1.dylib has been included in the SDK because there can be old frameworks that still want to be linked against the old version.

The two versions might have very similar interfaces in the header so you won't see any real differences when you compile and run, but in future versions the older versions might get removed and new ones added which will make your project break when linking.

If I understand it right, the linker will dereference file links so it will find the right version and keep that dylib name and dynamically link against that when the app starts. So the libz.dylib won't be the path used (more than at compile time).

I see this in my Xcode installation in the 4.3 SDK

/Developer/.../SDKs/iPhoneOS4.3.sdk/usr/include/zlib.h

/* zlib.h -- interface of the 'zlib' general purpose compression library
  version 1.2.3, July 18th, 2005

  Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler

libz.dylib

/Developer/.../SDKs/iPhoneOS4.3.sdk/usr/lib/libz.dylib -> libz.1.2.3.dylib

---

You can easily see in the finder how they work. In XCode, "Show in Finder" one of the libraries. Now click once on libz.dylib and "Get Info". You'll see that "Original" is:

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/libz.1.2.5.dylib (as of XCode4.2 with iOS 5 SDK)

So it's a symbolic link to version 1.2.5 for now. In the future it will update to the latest 1.x.x. You can examine all of the various versions this way.

---

Just link with libz.dylib instead of a specific version and compiler will link the available version on installed SDK. Linker error may come in case of linking with some specific version that is not available in currently installed SDK.

---

You can use use libz.1.2.5.dylib instead of libz.1.2.3.dylib

Replace libz.1.2.3.dylib -----> libz.1.2.5.dylib