Boost logo

Boost-Build :

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


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk