id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
1342,dylib library names broken in Mac OS X,jmmv@…,René Rivera,"The 1.34.1 release installs dylib files in Mac OS X which have broken library names in them.  For example:

calypso:~/pkg/lib> otool -D libboost_date_time-mt.dylib 
libboost_date_time-mt.dylib:
bin.v2/libs/date_time/build/darwin/release/threading-multi/libboost_date_time-mt.dylib

Note that the response contains the build-time path to the library, not the installed one.  So this broken name ends up bundled in binaries built against boost, which later do not work because of this problem.  An example using monotone:

calypso:~> mtn
dyld: Library not loaded: bin.v2/libs/regex/build/darwin/release/threading-multi/libboost_regex-mt.dylib
  Referenced from: /Users/jmmv/pkg/bin/mtn
  Reason: image not found
Trace/BPT trap

I've found the -dylib_install_name option for ld(1) or -install_name in libtool(1) that are meant to set this internal name in libraries, when this name differs from the one used with -o.  Unfortunately, I do not know enough of Boost.Build to fix this myself.

As I understand it, to build a library that goes in /usr/local/lib/libfoo.dylib, you either do:
$ g++ -dynamiclib -o /usr/local/lib/libfoo.dylib x.o
Or:
$ g++ -dynamiclib -o libfoo.dylib -Wl,-install_name -Wl,/usr/local/lib/libfoo.dylib x.o
But boost is currently doing:
$ g++ -dynamiclib -o bin.v2/blahblah/libfoo.dylib x.o
The third case is very similar to the first one except that it is using a temporary name instead of the final one.

So the library name ends up pointing to a temporary directory that disappears.  darwin.jam has to be fixed to pass the correct -install_name flag to the linker as shown in the second line above.",Bugs,closed,To Be Determined,build,Boost 1.34.1,Showstopper,fixed,,