Since my average day involves last minute deployment on never_seen_before, often remote systems, I like my software self contained.
When working with 3rd party OSX dylib libraries, embedding everything you need in your bundle sometimes proves to be problematic and, as soon as you try to link, you get an ugly:
dyld: Library not loaded
This happens because your library is not were it expects to be; to see were your library wants to be placed, you simply have to open a terminal and:
$ otool -L /pathToLib/yourLib.dylib
The output will look something like this:
/usr/lib/yourLib.dylib (compatibility version 1.0.0, current version 1.0.0)
which means that if you put yourLib.dylib in /usr/lib/, your software will magically start to work.
If you can’t recompile the library, there’s not much you can do to convince it to live happily in a different folder; luckily you can still tell your application to ignore what the library is saying and to look for it in a different place. Back to your terminal:
$ install_name_tool -change /usr/lib/yourLib.dylib /pathToLib/yourLib.dylib /pathToApp/AppName.app/Contents/MacOS/AppName
Now when you double click on your app, it will run correctly.
Cool: this trick allows you to put a dylib wherever you wish, so you can use it to embed a library in your bundle. I’m going to show the steps needed to do it in an OpenFrameworks project, but it’s going to be more or less the same for any XCode project:
- open you XCode project and drag your dylib library in the
frameworks/3rd party frameworksgroup
- go to the
Build Phasespage, scroll down to
Copy Files, set
Destinationto Frameworks and add your dylib to the list: this will copy the library into the
Frameworksfolder in your bundle.
- still in the
Build Phasespage, scroll up to
Run Scriptand add the line that will tell your app where to look:
install_name_tool -change /usr/lib/yourLib.dylib @executable_path/../Frameworks/yourLib.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/MacOS/$PRODUCT_NAME";