Home/ Questions/Q 6230631
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T09:47:00+00:00

I asked this in a comment but this seems like an issue that deserves

  • 0

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 discovered 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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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
    • 0