2

I have an issue where I'm developing on one system where Boost is installed on:

/usr/include
/usr/lib

On a system I will deploy this on, the libboost libraries are at:

/nfs/mount/boost
/nfs/mount/lib

And I can't go about changing every system I deploy on to install libboost in the same place.

Is there a way to either:

  1. include libboost as part of the binary executable such that loading from the system lib paths is not needed.
  2. make the executable search for different directories when trying to load to libboost?

I'm using g++ 8

jkang
  • 483
  • 7
  • 19
  • I thought static linking was the default for Boost. You have decided to use the dynamic Boost libraries instead? – JaMiT Aug 27 '20 at 21:39
  • Oh, I should check: which of the not header-only Boost libraries do you need? – JaMiT Aug 27 '20 at 23:24
  • Hmm, does static linking solve this? I use ProgramOptions, which I think is compiled. I'll also clarify my question to say "load" instead of "link" – jkang Aug 27 '20 at 23:40
  • 1
    Does this answer your question? [What do 'statically linked' and 'dynamically linked' mean?](https://stackoverflow.com/questions/311882/what-do-statically-linked-and-dynamically-linked-mean) – JaMiT Aug 28 '20 at 04:03

1 Answers1

-1

Sounds like you need a more sophisticated build environment.

I'm not sure what you mean here:

  1. include libboost as part of the binary executable such that linking is not needed

Linking is not something you can skip. If you are trying to avoid distributing .dll/.so files with your executable, you need to avoid using the portions of the boost library that require compilation of the boost binaries (i.e. those not listed here https://www.boost.org/doc/libs/1_62_0/more/getting_started/windows.html#header-only-libraries).

Of course, that is not often the case. So...

  1. make the executable search for different directories when trying to link to libboost?

This will never work reliably as you scale and is a nightmare in the CI world. This is where package managers such as conan (https://conan.io/) come to save the day. Delegating the package management to a third-party is the most reliable way of getting your code to build across multiple environments/platforms.

Also, building your executable and distributing it are separate operations. Any dynamically linked libraries will need to be discoverable on the system path at runtime.

aclark
  • 1
  • 1
  • The OP probably means "load" instead of "link". – JaMiT Aug 27 '20 at 23:26
  • Ah, that makes more sense. Still, Even if using header-only portions of boost the build environment still needs to find the includes. This is not a boost-specific issue. There will be other dependencies. Use a package manager if you need to build in diverse environments. – aclark Aug 31 '20 at 16:47
  • The OP is having issues with deployment, which implies that the executable was built. So apparently the build environment did find the includes and the libraries. There is no mention of needing to build in diverse environments. – JaMiT Aug 31 '20 at 21:58