Open jefftrull opened 4 years ago
Or, alternatively, add RPATH instead of RUNPATH to the executable, because it's inherited by dependencies. I'm not sure how this would translate to a linker option though.
FWIW CMake adds RUNPATH to shared libs with dependencies
The relevant portion is here, I suppose: https://github.com/boostorg/build/blob/cf9933462a2a942bd1b95b839c1b2e427201fe8f/src/tools/generators/linking-generator.jam#L64-L73
Further information: b2 uses -rpath
, which by default sets DT_RPATH. However, Debian have decided to patch their ld
to use --enable-new-dtags
by default, which sets DT_RUNPATH instead. If we want to revert to the old behavior on Debian, we need to pass -Wl,--disable-new-dtags
.
Reference: https://stackoverflow.com/questions/52018092/how-to-set-rpath-and-runpath-with-gcc-ld
Thank you for your contributions. Main development of B2 has moved to https://github.com/bfgroup/b2 This issue has been automatically marked as "transition" to indicate the potential for needing transition to the new B2 development project.
I'm trying to eliminate the deprecated Timer API usage from Boost.Wave. The new API seems to required linking to the Timer library (i.e. is no longer header-only). I added
/boost//timer
to the Wave tool dependencies above this line.Now, when I run the standalone Wave tool I get the following error message:
error while loading shared libraries: libboost_chrono.so.1.73.0: cannot open shared object file: No such file or directory
After some investigation it appears that while the wave executable has a
RUNPATH
set,libboost_timer.so.1.73.0
does not, and it depends on Chrono. The wave executable'sRUNPATH
does include the location oflibboost_chrono.so.1.73.0
- but this is apparently not enough.IMO bjam should be adding a RUNPATH to
libboost_timer.so.1.73.0
for its Chrono dependency. When I do this manually everything works.