Re: [Boost-build] Building on OSX with link=shared

Subject: Re: [Boost-build] Building on OSX with link=shared
From: Ian Emmons (ian_at_[hidden])
Date: 2016-01-24 16:45:08

On Jan 21, 2016, at 4:29 AM, Raffi Enficiaud <raffi.enficiaud_at_[hidden]> wrote:
> Le 21/01/16 07:38, Vladimir Prus a écrit :
>> On 19-Jan-16 7:43 AM, Ian Emmons wrote:
>>>> On Jan 15, 2016, at 2:27 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>>>> 
>>>> Does no one know how to do this?  Have boost shared libraries ever
>>>> been tested on OSX?
>>>> 
>>>> 
>>>> On 1/14/16 4:28 PM, Robert Ramey wrote:
>>>>> I'm trying to build and test the serialization library on my OSX
>>>>> machine.  This works fine when I use link=static.  But when I'm using
>>>>> link=shared - I get the following message.
>>>>> 
>>>>> ../../../tools/library_status/library_test.sh -j4 toolset=clang-03
>>>>> variant=debug link=shared test_iterators  >b2.log  &
>>>>> 
>>>>> dyld: Library not loaded: @rpath/libboost_filesystem.dylib
>>>>>   Referenced from:
>>>>> /Users/robertramey/WorkingProjects/modular-boost/libs/serialization/test/../../../bin.v2/libs/serialization/test/test_iterators.test/clang-darwin-03/debug/test_iterators
>>>>> 
>>>>> 
>>>>>   Reason: image not found
>>>>> Trace/BPT trap: 5
>>>>> 
>>>>> It seems that the test programs are not finding the shared libraries
>>>>> being built.
>>>>> 
>>>>> Does anyone know what the most convenient way to fix this is.  If I
>>>>> recall, it used to work sometime ago.
>>>>> 
>>>>> Robert Ramey
>>> 
>>> 
>>> 
>>> Robert,
>>> 
>>> Sorry for the delay, but I've been working too hard to check my home
>>> email for a few days.
>>> 
>>> I ran into this problem recently as well.  It seems to be related to
>>> changes in OSX made in the last major release, version 10.11, a.k.a.
>>> El Capitan.  One set of changes went under the heading of System
>>> Integrity Protection (SIP) [1, 2].  Among the changes was disabling
>>> DYLD_LIBRARY_PATH and other environment variables related to the
>>> dynamic linker (dyld).
>>> 
>>> I solved this by first building Boost's and my shared libraries in the
>>> normal way, and then using install_name_tool to change the install
>>> names of the resulting .so files.  You can find discussions of install
>>> names, how they are used to load shared libraries, and how they can be
>>> changed in [3, 4, 5].
>>> 
>>> I know that's not a simple recipe for success, but I hope it gets you
>>> on the right path.
>> 
>> Ian,
>> 
>> so it sounds like in order to run an executable that uses shared library
>> X at path P, the install_name inside X should be set to P prior to
>> linking of the executable? And then, when installing library X to its
>> final location, the install_name should be changed again to its final
>> install location?
>> 
>> I suppose it can be accomplished, although the number of gratuitous
>> changes in El Capitan is quite ridiculous.
>> 
> 
> I think the name of the library can be set prior to the link as a link argument. But it also means that the "install" target is not relocatable.
> 
> Additional question: can we use @rpath at all in the names?
> 
> Raffi

Vladimir:  See my previous post in reply to Robert Ramey.  It contains some other ideas about how you might fix this.

Raffi:  The combination of Boost.Build and clang set the install name of each shared object x.so to "@rpath/x.so", and therefore you can use @rpath specifications in the dependent executable to cause the OS to search in the right place(s).  This wasn't a good fit for my particular case, but it might be a good solution for you.

-Ian