Re: [Boost-build] <dll-path>'$ORIGIN' is prefixed by path with gcc

Subject: Re: [Boost-build] <dll-path>'$ORIGIN' is prefixed by path with gcc
From: Chambers, Matthew (matt.chambers42_at_[hidden])
Date: 2018-08-25 00:02:22

On 8/24/2018 5:17 PM, Steven Watanabe via Boost-build wrote:
> On 08/24/2018 02:18 PM, Chambers, Matthew via Boost-build wrote:
>> Jamroot.jam:
>> build-project p ;
>>
>> p/Jamfile.jam:
>> lib a : a.cpp : <link>shared ;
>> exe p : p.cpp : <library>a ;
>> install install : p : <install-dependencies>on <dll-path>'$ORIGIN' ;
>>
>> ./b2
>> <snip>
>>
>> objdump -x -a p/install/p | grep RPATH
>>  Â  RPATHÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â  p/$ORIGIN
>>
>> I expected dll-path to be set unmodified. Is this intended, and if so,
>> how do I prevent it? I haven't pinpointed exactly when this changed, but
>> it worked a couple years ago. This is using master at
>> c3dc95d3ac0219a0f774e6d382ed91d290cbde80.
>>
> This is broken because dll-path is a path feature,
> which causes $ORIGIN to be interpreted as a path
> relative to the containing project and is adjusted
> to be relative to the current working directory.
> As far as I can tell, it's always worked this way,
> but if you run b2 from p/ it should do what you want.
Something changed when I updated my boost-build code. It used to take the '$ORIGIN' text verbatim.

> Do relative paths even make sense for dll-path?
Relative paths after $ORIGIN could make sense, e.g. '$ORIGIN/lib/vendor1;$ORIGIN/lib/vendor2'. But not before. And without origin I don't 
see it making sense either.

> The right thing might be to remove the path attribute
> from dll-path which will cause the argument to be
> passed through literally.
Thanks, I'll try this.

Have a good weekend!
-Matt