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 frameworks group
- go to the
Build Phases page, scroll down to
Copy Files, set
Destination to Frameworks and add your dylib to the list: this will copy the library into the
Frameworks folder in your bundle.
- still in the
Build Phases page, scroll up to
Run Script and 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";
Read Full Post »