dylib
files on the mac, so
files on Linux systems) are modules of code loaded at run time; the binary executables (or other object files) only store a path to the shared library file (and sometimes a version number). Sometimes this path is wrong: either the shared library has moved, or in the case of Boost's generated libraries, it compiled in a relative path rather than an absolute path. I ran into this issue before with CUDA's dynamic library (I was flabbergasted that it didn't automatically store an absolute path when I passed an absolute path to the linker), and my half-kludge of a fix was to add the environmental variable DYLD_LIBRARY_PATH=:/usr/local/cuda/lib
.Well, it happened again today; Boost was failing with dyld not loaded, image not found. I hit upon the google query that brought up an Apple developer page that explained the issue well.
I invented a general solution, since this will probably happen again to me. If you have shared libraries that don't use an absolute path (or don't use the right path),
cd
to the directory in which they reside and run the following command:for f in *.dylib; do sudo install_name_tool -id $(pwd)/$f $f; done
Ta-da!
1 comments:
Blegh you are nauseatingly clever, aren't you?
Post a Comment