0

I'm trying to use the EPEL package boost169-devel on CentOS 8. I'm trying to build my C++ source code with the boost library version 1.69 from this package.

I see that that package has header & .so files in non-standard locations, /usr/include/boost169 instead of /usr/include for headers and /usr/lib64/boost169/ instead of /usr/lib64 for .so.

I know I can hack my build files to make it work -- munge my gcc's -I to have /usr/include/boost169 in front and add a -L /usr/lib64/boost169 in the beginning. But my build files are also used to build on other distros, so I'm looking for a cleaner way that does not involve introducing a lot more complexity to my build system. E.g. for gcc-toolset-9, which also installs things in non-standard locations, one can use scl enable gcc-toolset-9 bash to have the paths setup properly without caring about the implementation details. Is there a prescribed way or cleaner way for dealing with the non-standard location of boost169-devel than manually munging -I and -L?

Joshua Chia
  • 1,760
  • 2
  • 16
  • 27
  • What build tool are you using? autotools? cmake? plain old makefiles? Both autotools and cmake support pointing to non-standard install locations at configure time. – omajid Jul 30 '20 at 14:46
  • I'm using waf. I'm hoping to use the non-standard paths in a way that my build tool doesn't need to care about. Otherwise, I'd have to add more code to my wscript so I may be better off building boost from source myself and installing it to /usr/local like I do for other libraries not installed from distro package. – Joshua Chia Jul 31 '20 at 00:46

0 Answers0