Re: [Boost-build] Building boost shared libraries with their paths embedded?

Subject: Re: [Boost-build] Building boost shared libraries with their paths embedded?
From: Vladimir Prus (ghost_at_[hidden])
Date: 2012-05-13 10:10:49

On 13/05/12 14:10, Bruce Stephens wrote:
> On Sun, May 13, 2012 at 6:52 AM, Vladimir Prus<ghost_at_[hidden]>  wrote:
>
>> Bruce,
>>
>> there's no solution for your problem right now. What would you recommend? Is
>> this either:
>>
>> - Using full installed path to the library as -install_name (which would
>> require that prefix=
>> be passed)
>>
>> - Rewriting install name on installation. Note that we already pass
>> -headerpad_max_install_names
>> to reserve space for longer names.
>>
>> - Petition Apple to implement real rpath?
>>
>> - Anything else?
>
> Ah, OK. So the problem's just on OS X, because on other platforms I
> can build with dll-path=...?
> That seems to work, so I'll assume that's the case. Don't know why I
> hadn't thought to try that
> before.

I am surprised that it works. dll-path specifies a path in which an executable
or libraries should look for dependency libraries. So, if you specify dll-path
when building a Boost library, it will look in the specified directories for its
dependencies, but that should not help the clients very much.

> In that case can't I get what I want (not a general solution,
> admittedly) by changing the Darwin
> link.dll so it prefixes install_name with dll-path? (All we want, at
> least for the moment, is to get
> the boost libraries built in this way; we don't expect to be using
> Boost.Build for anything else.)

Why don't you just 'fix' install names after the builds, using a shell script?

HTH,
Volodya