Vladimir Prus wrote:

Mike Jackson wrote:

...

Example for the filesystem is:

532:[mjackson@Thor:boost]$ otool -L /Users/Shared/Sandbox/boost- install/lib/libboost_filesystem-1_35.dylib /Users/Shared/Sandbox/boost-install/lib/libboost_filesystem-1_35.dylib: bin.v2/libs/filesystem/build/darwin/release/ libboost_filesystem-1_35.dylib (compatibility version 0.0.0, current version 0.0.0) bin.v2/libs/system/build/darwin/release/ libboost_system-1_35.dylib (compatibility version 0.0.0, current version 0.0.0)

Oh, cool. Now we actually have one boost library depending on another?

And why does OSX embed the path?

The trunk darwin.jam doesn't embed the path. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On Feb 1, 2008, at 11:17 AM, Vladimir Prus wrote:

Mike Jackson wrote:

...

I just checked out and built boost on OS X 10.4 and there is a problem with the "install_name" or "rpath" on the dynamic libraries that are built. The "install_name" that is embedded in the libraries are basically useless as they do not contain a correct path to the libraries.

You might want to raise boost.build questions on the boost- build@lists.boost.org mailing list, not here.

To, me this was a bug so I followed the directions on <http:// www.boost.org/more/bugs.htm> : Submit a bug report to either boost-users list, boost mailing list, or our bug tracking facility; submitting it to either of the mailing lists is a preferred way - because many of the Boost developers read the lists on a daily basis, this way you are likely to get a quicker response, and the discussions that often arise there from (possible) bug reports are quite interesting and educational as well;

...

Example for the filesystem is:

532:[mjackson@Thor:boost]$ otool -L /Users/Shared/Sandbox/boost- install/lib/libboost_filesystem-1_35.dylib /Users/Shared/Sandbox/boost-install/lib/ libboost_filesystem-1_35.dylib: bin.v2/libs/filesystem/build/darwin/release/ libboost_filesystem-1_35.dylib (compatibility version 0.0.0, current version 0.0.0) bin.v2/libs/system/build/darwin/release/ libboost_system-1_35.dylib (compatibility version 0.0.0, current version 0.0.0)

Oh, cool. Now we actually have one boost library depending on another?

Yes, It looks that way.

And why does OSX embed the path? Standard GNU tools will only embed "soname" -- which is a name embedded in a shared library that tells by what name other libraries should refer to it. Is something like that present on OSX?

Right, this is called the "install_name" for dylibs. It can be a file name or an entire path or some "special paths" like "@executable_path/../". When one library links to another this "install_name" is used so that all the libraries and executables know how to find each other. An example should clarify this. libA.dylib has an "install_name" of "libA.dylib" libB.dylib has an "install_name" of "/Users/Shared/Sandbox/lib/ libB,dylib" libC.dylib has an "install_name" of "@executable_path/../lib/libC.dylib" Now we have an executable called foo that links against all three libraries. In order for foo to run successfully, libA.dylib must be in a folder defined in the DYLD_LIBRARY_PATH, libB must be located in /Users/Shared/Sandbox/lib/ and libC must be located in a "../lib/" which is a directory that is relative to foo. That, in a nutshell is how OS X linking works.

...

There are a couple of choices for the "Correct" value. The best (IMHO) would be to put in the absolute path to the installed library, so on my system that would be:

/Users/Shared/Sandbox/boost-install/lib/ libboost_filesystem-1_35.dylib

We could also put _no_ path on the install_name, but that requires the user to additionally set the DYLD_LIBRARY_PARH which Apple discourages.

On what grounds? Is there anythink like Linux rpath -- where a library includes a list of paths where dependent libraries should be searched?

Yes, see above. This is called "install_name". The value can be changed using "install_name_tool" (which is installed with the OS X developer tools) under some circumstances. That circumstance is the additional use of "-headerpad_max_install_names" flag during linking.

...

The fix would be to add the following to the "actions link.dll bind LIBRARIES" section of the boost/tools/build/v2/tools/darwin.jam file:

-headerpad_max_install_names -install_name "{Install_prefix_lib_location}$(<[1]:D=:S=.dylib)" .....

I do not know anything about bjam so I have no idea how to get the "Install_prefix_lib_location". Could some one tell me how to get at that value somehow and I will create a patch.

You can't. It's quite possible to build Boost, and then install it to 3 different places -- on Linux that involves plain file copy. What does -install_name actually does?

using -install_name encodes the equivalent of a linux rpath into the library so that when it is "installed" and other libs/exes link to the library those libs/exes know where to find it. So you are telling me that there is NO WAY that in the boost/tools/ build/v2/tools/darwin.jam file we can get at the --prefix=[value] from configure? If there is really no way to get at that value then I would use - headerpad_max_install_names -install_name "$(<[1]:D=:S=.dylib)" instead. At least that way the programmer only have to set DYLD_LIBRARY_PATH (which is still discouraged by Apple) or run "install_name_tool" manually on all the boost libraries. I have a script that I wrote that I use to change all the "install_name" on all the boost libs after compilation. ---- Mike Jackson OS X Build Specialist