Libraries versus bundles in Mac OS X

Mac OS X has this wonderful thing: bundles, where you stuff everything an application may need to run far from its development environment, including kernel drivers. But the most common objects included in a bundle are dynamic libraries.

UNIX-style libraries are a bit difficult to move into the bundle; the executable still tries to find them in original locations. And your UNIX-style libraries may themselves refer to other UNIX libraries.

But then there is install_name_tool. Here goes an example of usage:

install_name_tool -change \
    /Users/epx/Qt/lib/QtGui.framework/Versions/4/QtGui \
    @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui \
    somelibrary.dylib

where the first path is the original reference to a UNIX library, the second path (with the @executable_path) is the new reference that object must follow, and somelibrary.dylib is the library or executable that you are trying to convince to search the library inside the bundle, and not in an absolute path of the filesystem.

By the way, you can check which libraries an executable or library refers to by

otool -L somelibrary.dylib

and weed out the absolute references that are not standard Mac OS X libs.

My use case was a Qt application which depended on an external library, which itself linked to Qt too. The semi-automatic macdeployqt does much of the bundle work (it copies the Qt frameworks into the bundle and updates the executable accordingly), but I had another library that needed to be copied manually, and still referred to Qt as an absolute path.

Many thanks to Henry Vieira @ INdT for this hint which saved my day :)