Re: <dll-path>'$ORIGIN' is prefixed by path with gcc
"Chambers, Matthew via Boost-build" <[email protected]>
| Newsgroups | gmane.comp.lib.boost.build |
|---|---|
| Message-ID | <[email protected]> |
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