Cannot create dylib for distribution that works on OS X 10.5 (building in 10.6 environment)

Question

I'm trying to distribute cairo (1.10.2) with my application. I can create the necessarily dylibs using Homebrew but they are dependent on versions of other dynamic libraries that aren't present in OS X 10.5 (libfontconfig, libfreetype, and others located primarily in /usr/X11/lib).

I assume to solve this I want it to be using the dylibs in /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib rather than the libraries in /usr/X11/lib. I've tried anything I could find for targeting cairo against the 10.5 SDK.

• Setting MACOSX_DEPLOYMENT_TARGET environment variable to 10.5 (before calling brew or using Homebrew's ENV)
• Setting SDKROOT environment variable to "/Developer/SDKs/MacOSX10.5.sdk" (before calling brew or using Homebrew's ENV)
• Adding -mmacosx-version-min=10.5 to the CFLAGS, CXXFLAGS, and LDFLAGS in the Homebrew formula for cairo.
• Adding -sysroot/-isysroot /Developer/SDKs/MacOSX10.5.sdk to the CFLAGS, CXXFLAGS, and LDFLAGS in the Homebrew formula for cairo.
• Adding -I$(SDKROOT)/usr/X11/include and -I$(SDKROOT)/usr/X11R6/include to the CFLAGS and CXXFLAGS in the Homebrew formula for cairo.
• Adding -L$(SDKROOT)/usr/X11/lib and -L$(SDKROOT)/usr/X11R6/lib to the LDFLAGS in the Homebrew formula for cairo.

While building cairo it has -I/usr/X11/lib on the gcc commands (with my options tacked on the end) so I imagine it's hitting that first. I'm not sure how to get rid of that so it uses my options. I thought isysroot would make it so the include and library paths were rerooted in the SDK but -isysroot doesn't seem to have any effect.

Gamali

You might consider using MacPorts to supply the necessary 3rd-party libs for this use case rather than Homebrew. MacPorts generally supports cross-release and -architecture building. Just edit the settings files in /opt/local/etc/macports and /opt/local/etc/variants. – Particulate

I was originally using macports but couldn't seem to get it to build with the deployment target I wanted (tried universal_target). With Homebrew I got the cairo dylib itself to support 10.5 (seemingly) but it still references those system libraries. – Gamali

Answer 1

You should be able to use install_name_tool to change where cairo looks for its libraries. (I have no idea what cairo is. I'm assuming it's a dylib. If not, my confidence in this solution goes down considerably.)

Here's a made-up example that you should be able to adapt.

First, use otool -L to see which libraries cairo is using. In this example I'm working with libopencv_imgproc.2.3.1.dylib, but you'll use your cairo library's file name instead:

$ otool -L libopencv_imgproc.2.3.1.dylib 
libopencv_imgproc.2.3.1.dylib:
    lib/libopencv_imgproc.2.3.dylib (compatibility version 2.3.0, current version 2.3.1)
    lib/libopencv_core.2.3.dylib (compatibility version 2.3.0, current version 2.3.1)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

Then use install_name_tool -change to change whichever paths you need to change. The first parameter is the current library path, the second is the desired library path, and the third is the library file. I'm telling it to look for libz.1.dylib in /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/ instead of /usr/lib:

$ install_name_tool -change /usr/lib/libz.1.dylib /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libz.1.dylib libopencv_imgproc.2.3.1.dylib 

Repeat this for every library whose path you need to change. otool -L shows us that the change was made:

$ otool -L libopencv_imgproc.2.3.1.dylib 
libopencv_imgproc.2.3.1.dylib:
    lib/libopencv_imgproc.2.3.dylib (compatibility version 2.3.0, current version 2.3.1)
    lib/libopencv_core.2.3.dylib (compatibility version 2.3.0, current version 2.3.1)
    /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

In my example (and perhaps in your application) my library expects to find itself somewhere other than my application bundle, so I need to change that as well with install_name_tool -id. I'm copying the library to my application bundle's Frameworks folder so I'm telling it to look there:

$install_name_tool -id @executable_path/../Frameworks/libopencv_imgproc.2.3.1.dylib libopencv_imgproc.2.3.1.dylib

You can put the install_name_tool invocations in a Run Script build phase. If you are copying the library into your application bundle's Frameworks folder, you should prepend the library name with $BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/ to ensure that the script can find the library.

Keene

This should get me there, I think. I've been using macdylibbundler to pull cairo into my bundle and fix my executable's dylib path to it but it's set up (rightly) to ignore libraries in /usr/lib (as they should be on the user's system already). I didn't know how to change the paths stored in the dylib manually though so you've helped me solve that so I should be able to handle any remaining issues. Cairo is the vector graphics library used by GTK+, Firefox, and many others. – Gamali