How to force Boost to use rpath?

Question

I have to build Boost outside the "usual" directory tree (i.e., /custom/dir instead of /usr), which is not that much of a problem: Just pass --prefix=/custom/path to ./runscript.sh / ./bjam, and there you go.

Or so I thought.

The problem is that some of the Boost libraries depend on each other, and - using the default build process going through ./bootstrap.sh / ./bjam - it seems that the --prefix path is not added to the library search path for the Boost libs, i.e. no -Wl,-rpath is applied. That means that Boost libraries depending on other Boost libraries cannot find those at runtime.

My application - linking those /custom/path Boost libraries - already fails at ./configure stage because libboost_filesystem.so cannot find libboost_system.so, even though I passed -Wl,-rpath=/custom/path/boost/lib to my own compiler line (i.e. the correct path to the Boost libs, I double-checked that libboost_system.so is there).

Now, to avoid heavy-handed methods like setting LD_LIBRARY_PATH, I'd like to build Boost in a way so that all the Boost libraries have the proper search path for the other Boost libs compiled into them. However, I was unable to find the proper procedure for that. Can anybody help me?

Belga

Answer 1

I needed to do this recently for another project, although I needed to use $ORIGIN to make the path relative to the location of boost's shared objects.

This required the following on a bash command line:

./b2 hardcode-dll-paths=true dll-path="'\$ORIGIN/../lib'" --prefix=$MY_PREFIX install

Figuring out the magic collection of characters to get that $ORIGIN placed correctly in the shared object took a bit of trial and error, so I hope writing the answer here helps others to avoid fumbling around with this.

Birthmark

Thanks, this answer saved my day. – Levator

Indeed, and it surpassed the originally "correct" answer in helpfulness. – Belga

Truthfully, if I hadn't written this here, I would have forgotten, and had to figure it out again. This way, at least I'll find it when I desperately search around the internet for what I did a year or more ago. – Birthmark

in new version this does not work. dll-path="'\$ORIGIN/../lib'" will translate to -R //../lib instead of -R \$ORIGIN/../lib – Underbelly

Wang, I could not duplicate your issue with boost-1.72.0, on a bash prompt, on a Mandrake Linux system. Were you using bash? – Birthmark

Answer 2

You can add compiler & link options during build from the command line with:

bjam hard-code-dll-path=true dll-path=/custom/path

There's a FAQ item in the Boost Build docs about this (see B2 docs).

Encamp

Ahem... apparently this stopped working with Boost 1.45.0 (exact same invocation). I could not find mention of any relevant changes in 1.45.0; do you by happenstance know more than I do? – Belga

Hm, don't know more than you do on this one. But if it stopped working, I would consider it a bug. And should be reported as such. – Encamp

1.62 is OK with this options: hardcode-dll-paths=true dll-path=/custom/path/lib – Roister

on boost 1.69 I need to use hardcode-dll-paths=true insted of hard-code-dll-path=true – Opiumism