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
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
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
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
which returns the shared library dependencies. In my case, on my linux computer, I see the line
libboost_program_options.so.1.46.1 => /usr/lib/libboost_program_options.so.1.46.1 (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
I now clean and remake by typing
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
Once the code compiles, I can try running by typing
The code returns
./compute_sdot: error while loading shared libraries: libboost_program_options.so.1.60.0: cannot open shared object file: No such file or directory
I confirm that the executable cannot find the shared library by typing
which returns a line
libboost_program_options.so.1.60.0 => 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)
On my mac, I use instead the DYLD_LIBRARY_PATH environment variable:
Now, on my linux or cygwin computer, when I type
I get the usage statement, and when I type
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
libboost_program_options.so.1.60.0 => /users/mbradle/boost/stage/lib/libboost_program_options.so.1.60.0 (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)
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.