Using Boost compiled libraries

In a previous post, I mentioned that NucNet Tools examples now depend on the Boost program options library, which is a compiled library. This should present no problem to users who install Boost through the normal instructions. Neverthless, there may be users who wish to work with their own installation of Boost. In this post I will show how to do this.

I begin by checking out Boost with git. Once I've done this, I change into the resulting boost directory and perform the set up by typing

cd boost


This creates the executable b2 to build the libraries. The executable b2 has a number of options, including where to stage the resulting libraries. The options can be found by typing

./b2 --help

or by looking at the appropriate Boost web page. In my case, I will simply use the defaults and type


Once the compilation is finished, the libraries are left in the directory stage/lib, unless I've specified some other directory with an option to b2.

I can now test everything by changing into my Nucnet Tools directory and compiling. I type

cd ~/nucnet-tools-code/

svn up

cd examples/thermo

make clean

make compute_sdot

This will compile the compute_sdot code with the default library installed on my system. I type


which correctly gives me the usage statement for the code. I then type on linux or cygwin

ldd ./compute_sdot

which returns the shared library dependencies. In my case, on my linux computer, I see the line => /usr/lib/ (0x00007fe77462d000)

which shows that the code uses the default program_options library installed on the machine.

On my mac, I use the command

otool -L ./compute_sdot

to get the shared file dependencies. I now link instead to the Boost libraries I compiled. I type


On my linux computer I see


so my home directory is /users/mbradle. I therefore set the appropriate environment variables (in the bash shell) by typing

export BOOST_DIR=/users/mbradle/boost

export BOOST_LIB_DIR=/users/mbradle/boost/stage/lib

I now clean and remake by typing

make clean

make compute_sdot

If I get a conversion warning like

/users/mbradle/boost/boost/math/policies/error_handling.hpp:140:101: error: conversion to ‘int’ from ‘long unsigned int’ may alter its value [-Werror=conversion]
cc1plus: all warnings being treated as errors
make: *** [../../obj/math.o] Error 1

I can turn off those off by typing


make compute_sdot

Once the code compiles, I can try running by typing


The code returns

./compute_sdot: error while loading shared libraries: cannot open shared object file: No such file or directory

I confirm that the executable cannot find the shared library by typing

ldd ./compute_sdot

which returns a line => not found

The problem is that the program_options library is loaded at run time but I haven't yet told the computer where to find the library. In a linux or cygwin bash shell, I can specify this by adding my Boost library path to the LD_LIBRARY_PATH environment variable by typing (in my case)

export LD_LIBRARY_PATH=/users/mbradle/boost/stage/lib:$LD_LIBRARY_PATH

On my mac, I use instead the DYLD_LIBRARY_PATH environment variable:

export LD_LIBRARY_PATH=/Users/bradleymeyer/boost/stage/lib:$DYLD_LIBRARY_PATH

Now, on my linux or cygwin computer, when I type


I get the usage statement, and when I type

ldd ./compute_sdot

I see that the code loads the library from boost/stage/lib. For example, in my case, I get on the linux computer a line => /users/mbradle/boost/stage/lib/ (0x00007efe6bee7000)

Of course there are other approaches to using the Boost compiled libraries. For example, one could build them with static linkage so that it is not necessary to specify the path for run-time linking. Users with an interest or need in installing the libraries by hand can pursue these issues. As I said at the beginning of this post, however, most users will simply use the Boost compiled libraries installed via apt-get, Mac ports, or the cygwin installer. They will have no need for the above instructions.

Mac users may have issues because ports installs the multi-threaded compiled libraries with a -mt suffix, so the default compilation will not find the program options library and will fail. Users have two options. First, one may choose to compile the Boost libraries and link to them, as described above. Second, one may instead set the environment variable BOOST_MT by typing (in a bash shell)

export BOOST_MT=1

and cleaning and recompiling. In either case, you will need to export environment variables frequently. To have the computer do this automatically, you may want to add the appropriate lines to the bottom of your ~/.bash_profile or ~/.bashrc file, if you are using the bash shell. For other shells, see this page.

Posted by Bradley S. Meyer 2016-05-01


Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks