https://svn.boost.org/trac10/ticket/9141 <p> This was originally discussed in 2008 on the Boost.build mailing list in thread "Install_name wrong on OS X dylibs with latest CVS" </p> <p> To recap, building on MacOSX with seems to work, but the resulting shared libraries lack an absolute path in their install_name, so apps using them fail to load; instead, one gets an error like </p> <pre class="wiki">dyld: Library not loaded: libboost_thread.dylib Referenced from: a.out Reason: image not found Trace/BPT trap: 5 </pre><p> To work around this, the user can set DYLIB_LIBRARY_PATH to point to the libraries, but that's not very satisfying. Or the packager can use Apple's install_name_tool to set the absolute path at install time. </p> <p> This last bit was made possible by the fix to bug 1927. </p> <p> This should be documented, perhaps near where hardcode-dll-paths is documented. The document might say something like </p> <blockquote> <p> Note about building on MacOSX </p> </blockquote> <blockquote> <p> Shared libraries on MacOSX generally have their absolute path embedded in them in a field called install_name. This field is copied into any executable that links against them. The executable then looks exactly at that absolute path to find the library. If the library is not there, the executable will fail to load. If you use e.g. homebrew to install Boost, this is taken care of for you, but if you're building boost yourself, read on. </p> </blockquote> <blockquote> <p> With the default build of Boost, doing e.g. </p> <blockquote> <p> otool -D libboost_regex.dylib </p> </blockquote> <p> produces just a pathless filename, and doing </p> <blockquote> <p> otool -L a.out | grep libboost </p> </blockquote> <p> on a library linked against this will show that the executable is trying to load the library without a path. </p> </blockquote> <blockquote> <p> A user can work around this by add the install directory to the DYLIB_LIBRARY_PATH environment variable, but that's often not acceptable. </p> </blockquote> <blockquote> <p> A nicer way to work around this is to use Apple's install_name_tool to embed the library's full path inside the library at install time, e.g. </p> <blockquote> <p> install_name_tool -id /foo/bar/libboost_regex.dylib /foo/bar/libboost_regex.dylib </p> </blockquote> </blockquote> <blockquote> <p> (Alternately, you can patch the use of -install_name in tools/build/v2/tools/darwin.jam before building, but that's ugly.) </p> </blockquote> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/9141 Trac 1.4.3