Re: [boost] [Boost.build] Install_name wrong on OS X dylibs with latest CVS

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