CentOS Question posted in
The official documentation can be found here.

yum : using boost 1.69 instead of default (1.53) version on centos

I want to compile (c++/cmake) code using boost 1.69. I am on centos 7.

After :

sudo yum install boost-devel.x86.64

the code compiles fine, but using the default version which is 1.53.

If I look at the libraries installed in /lib64, I see for example:

>> ls -al  /lib64/ | grep boost_timer
lrwxrwxrwx.   1 root root          27 Jun  9 11:50 libboost_timer-mt.so -> libboost_timer-mt.so.1.53.0
-rwxr-xr-x.   1 root root       19848 Apr  1 04:26 libboost_timer-mt.so.1.53.0

The yum installation for boost 1.69 is also available. So I can do:

sudo yum install boost169-devel.x86_64

which updates for example the content of /lib64/

>> ls -al  /lib64/ | grep boost_timer
lrwxrwxrwx.   1 root root          27 Jun  9 11:50 libboost_timer-mt.so -> libboost_timer-mt.so.1.53.0
-rwxr-xr-x.   1 root root       19848 Apr  1 04:26 libboost_timer-mt.so.1.53.0
lrwxrwxrwx.   1 root root          24 Jun  9 11:50 libboost_timer.so -> libboost_timer.so.1.53.0
-rwxr-xr-x.   1 root root       19848 Apr  1 04:26 libboost_timer.so.1.53.0
-rwxr-xr-x.   1 root root       24104 Apr 23  2019 libboost_timer.so.1.69.0

also :

>> ls /usr/include/ | grep boost
boost
boost169

At this point my workspace still compiles, but still using 1.53.

I would like my workspace to compile using 1.69. I could achieve this by botching
FindBoost.cmake but this does not feel like the clean thing to do.

Also I tried (yum) removed boost-dev.x86-64, which removed the folder /usr/include/boost and the related so files in /lib64, which leaves for example:

>> ls -al /lib64/ | grep boost_timer
libboost_timer-mt.so.1.53.0
libboost_timer.so.1.53.0
libboost_timer.so.1.69.0

(note that there is no longer a “libboost_timer-mt.so”)

At this point I believe I could also get my workspace to compile by manually creating symbolic links /usr/include/boost and /lib64/libboost_*.so , but that does also not feel like the clean thing to do

(note: I created the symbolic link /usr/include/boost pointing to /usr/include/boost64/boost, and indeed cmake stopped complaining about BOOST_INCLUDE_DIR, but because I did not create the symbolic links for the libraries, cmake still complains about those).

Is there a cleaner alternative way to manual creation of symbolic links ?

edit : I did create manually symbolic links for all the boost related libraries the compiler was complaining about, and I can confirm this worked.

Tags:

2

Answers


  1. 0

    So there’s obviously BOOST_INCLUDE_DIR which you can use to control where boost headers, so why not just

    cmake -DBOOST_INCLUDEDIR=/usr/include/boost169 
  -DBOOST_LIBRARYDIR=/usr/lib64/boost169 
  ...
    Login or Signup to reply.
  2. 0

    The closest you can get to setting the default for CMake is to set BOOST_INCLUDEDIR and BOOST_LIBRARYDIR as environment variables. FindBoost.cmake explicitly looks for those variables in the environment (something CMake does not do by default). So you can globally export BOOST_INCLUDEDIR=/usr/include/boost169 and export BOOST_LIBRARYDIR=/usr/lib64/boost169 somewhere, or you can also wrap command invocations with, e.g., BOOST_INCLUDEDIR=/usr/include/boost169 BOOST_LIBRARYDIR=/usr/lib64/boost169 ./mybuild.sh (assuming that mybuild.sh ends up invoking CMake or handles those environment variables itself, of course).

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search