13

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?

DevSolar
  • 67,862
  • 21
  • 134
  • 209

2 Answers2

14

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.

Joseph Van Riper
  • 512
  • 7
  • 17
  • Thanks, this answer saved my day. – nglee Sep 03 '18 at 09:01
  • Indeed, and it surpassed the originally "correct" answer in helpfulness. – DevSolar Sep 03 '18 at 09:53
  • 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. – Joseph Van Riper Sep 19 '18 at 13:50
  • 1
    in new version this does not work. `dll-path="'\$ORIGIN/../lib'"` will translate to `-R //../lib` instead of `-R \$ORIGIN/../lib` – Wang Sep 03 '19 at 21:30
  • 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? – Joseph Van Riper Feb 23 '20 at 10:04
6

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).

GrafikRobot
  • 3,020
  • 1
  • 20
  • 21
  • 2
    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? – DevSolar Dec 07 '10 at 15:39
  • 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. – GrafikRobot Dec 13 '10 at 11:13
  • 2
    1.62 is OK with this options: `hardcode-dll-paths=true dll-path=/custom/path/lib` – laplasz Oct 12 '16 at 15:56
  • on boost 1.69 I need to use `hardcode-dll-paths=true` insted of `hard-code-dll-path=true` – Elvis Dukaj Jan 29 '19 at 15:57