From: Mike Jackson (imikejackson_at_[hidden])
Date: 2008-02-01 11:42:36
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_at_[hidden]
> 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_at_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