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

Subject: Re: [Boost-build] Building boost shared libraries with their paths embedded?
From: Bruce Stephens (bruce.r.stephens_at_[hidden])
Date: 2012-05-13 10:31:58

On Sun, May 13, 2012 at 3:10 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
> On 13/05/12 14:10, Bruce Stephens wrote:

>> 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.

You're right. I'm sure it worked for one platform I tried, but perhaps
I was mistaken, or perhaps what happened just made my test work
by accident.

>> 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?

Because I'm not sure how to do that (chrpath on GNU/Linux, I guess,
so that's another build dependency)? Hmm, overall, seems just as easy
for our current purposes to hack the link.dll rules.

Maybe we'll reconsider the whole approach (wouldn't be the first time
it's been changed) and make it simpler: remove all these paths
and just set rpath on libraries and executables (all the libraries end up in
on directory).