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

Subject: Re: [Boost-build] Building on OSX with link=shared
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-01-21 04:29:03

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