CODEWITHSUNDEEP
macosgcccairohomebrewdylib
eco
eco

Reputation: 2229

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

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.

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.

Upvotes: 2

Views: 819

Answers (1)

SSteve
SSteve

Reputation: 10728

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.

Upvotes: 1

Related Questions