<dll-path>'$ORIGIN' is prefixed by path with gcc

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

<dll-path>'$ORIGIN' is prefixed by path with gcc

Boost - Build mailing list
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
...found 20 targets...
...updating 8 targets...
gcc.compile.c++ p/bin/gcc-4.9.4/debug/a.o
gcc.link.dll p/bin/gcc-4.9.4/debug/liba.so
gcc.compile.c++ p/bin/gcc-4.9.4/debug/p.o
gcc.link p/bin/gcc-4.9.4/debug/p
common.copy p/install/a.cpp
gcc.link.dll p/install/liba.so
common.copy p/install/p.cpp
gcc.link p/install/p
...updated 8 targets...

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.

Thanks,
-Matt

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build

dll-path-test.zip (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: <dll-path>'$ORIGIN' is prefixed by path with gcc

Boost - Build mailing list
AMDG

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.

Do relative paths even make sense for dll-path?
The right thing might be to remove the path attribute
from dll-path which will cause the argument to be
passed through literally.

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: <dll-path>'$ORIGIN' is prefixed by path with gcc

Boost - Build mailing list

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
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build