How to set dyld_library_path in Xcode

Question

I am new to Xcode and Mac environment. I am using some dynamic and static libraries like boost, Clucene, etc. I have all the libraries under

MyApp.app/Contents/Resources

I want to set this path as the app's dyld_library_path. I tried editing XXX.plist file like

DYLD_LIBRARY_PATH /mypath/xxx

and setting the environment variable and argument in Xcode Nothing work.

but if I run a shell script like below without double clicking the app in my .dmg it works

#!/bin/bash
clear
cd /Volumes/xxx/myapp.app/Contents/MacOS
export DYLD_LIBRARY_PATH="/Volumes/xxx/myapp.app/Contents/Resources"
./myapp

I am sure this is not the proper way to do this. Is there proper way to set dyld_library_path every time I execute my app?

EDIT: It also works if u mannualy copy all ur library to clients /usr/lib path... i guess this is also not a proper way to do it.

Answer 1

Setting DYLD_LIBRARY_PATH isn't the best way to solve this problem. It's working around the fact that you've misinformed dyld as to where to find your libraries.

If you run otool -L MyApp.app/Contents/MacOS/MyApp you'll see the paths to the libraries that MyApp wants to load. If any library isn't found at the specified path then dyld will look for the library in the locations specified by DYLD_FALLBACK_LIBRARY_PATH. Setting DYLD_LIBRARY_PATH causes dyld to look for the library in the given locations ahead of the path that the otool command above returned.

The best way to solve this problem is to have your application specify the correct location of the libraries to start with so that setting DYLD_LIBRARY_PATH is not necessary. To do this you need to do the following:

1. Set the library identifier of each of the libraries that you're bundling inside your application to an @rpath-relative value. You can do this using install_name_tool -id @rpath/libFoo.dylib libFoo.dylib.
2. Add a Copy Files build phase to copy the libraries in to your application wrapper. MyApp.app/Contents/Frameworks is a typical location. MyApp.app/Contents/Resources should be avoided since binaries aren't resources in the usual sense of the term.
3. Specify a run path search path when linking your application. This gives the linker a list of paths to use to resolve any @rpath variables that it encounters in any load commands. If you're copying the libraries to MyApp.app/Contents/Frameworks you'll want to specify a run path search path of @loader_path/../Frameworks. You can do this via the LD_RUNPATH_SEARCH_PATHS (Runpath Search Paths) configuration setting in Xcode on your application target.

After doing all this you should be able to re-run the otool command mentioned above and see that the paths to your library are using @rpath-relative paths. You should then be able to run otool -lV MyApp.app/Contents/MacOS/MyApp and see an LC_RPATH load command specified with a value of @loader_path/../Frameworks. Finally, you should be able to run your application and see that it finds the libraries within its Frameworks directory without having DYLD_LIBRARY_PATH set!