Tag Archives: dylib

More on otool & install_name_tool

I think I may have cracked it…

The problem is, when compiling against 3rd party libraries in Xcode, the rpath search path for libraries that the executable uses to find libraries first, is inherited in from the library itself. So if the library is in /usrl/lib thats where the executable will look. Thats fine if the machine running your code has the library installed, but in the fashion of how Mac OS X makes application bundles with all dependencies residing inside, this doesn’t quite work. In fact xcode provides a copy build phase for libs/plugins. So you copy your libs across and yet your already compiled code does not know to look there.

The solution is to use install_name_change on both the dependencies and the main executable. Lets deal with your dependencies first. I will assume they are now all in the same plugin folder post build code.app/Contents/Plugins/…

Using otool -D lib.dylib returns the path that is presented by that library to the compiler. To change it you can use install_name_change with the argument -id.

install_name_tool -id “@executable_path/../Plugins/lib.dylib” lib.dylib

This alters the relative path of lib.dylib to the plugins folder of your bundle. Next you need to change each path in the main executable. You can find out the dependencies and their expected path of the executable using otool -L. For each dependency that needs changing use install_name_tool again with the argument -change.

install_name_tool -change “/usr/lib/lib.dylib” “@executable_path/../Plugins/lib.dylib” applicationname

This passes in the current expected path(found out using otool), then the new path, and finally the file you wish to make the operation on. Once you get a few libs worked out its worth chucking it in to a shell script to save you time. It seems odd to me that XCode does not make this easier for you considering how it encourages self encased bundles so much. There may be a more elegant way to do it, but I have not found it let.