I have two versions of boost installed on cluster. The old one is in standard location while the new one in my home directory. Since I have no su privilege I cannot delete the old one. I exported environment variables for boost (and for other libraries) as follows:
export PATH=/truba/home/osibliyev/boost/bin:$PATH
export LD_LIBRARY_PATH=/truba/home/osibliyev/boost/lib:$LD_LIBRARY_PATH
export LIBRARY_PATH=/truba/home/osibliyev/boost/lib:$LIBRARY_PATH
export CPLUS_INCLUDE_PATH=/truba/home/osibliyev/boost/include:$CPLUS_INCLUDE_PATH
After compiling with make, I get the following error at linking stage:
/usr/bin/ld: warning: libboost_serialization.so.1.64.0, needed by /truba/home/osibliyev/boost/lib/libboost_mpi.so, may conflict with libboost_serialization.so.1.53.0 /usr/bin/ld: loadmap.o: undefined reference to symbol '_ZN5boost7archive17archive_exceptionC2ERKS1_' /truba/home/osibliyev/boost/lib/libboost_serialization.so.1.64.0: error adding symbols: DSO missing from command line
lboost_serialization is already added to LDADD:
LDADD = -lmetis -lmpi -lboost_mpi -lboost_serialization -lboost_log -lboost_log_setup -lboost_thread -lpthread -lboost_date_time -lboost_filesystem -lboost_system -lboost_timer
I am sort of sure that the error is because of conflict because other libraries are linked without problem and only boost complains. This does not happen on my machine where there is only one boost version. What can I do to solve this error?
How your toolchain's header and library search paths are determined is implementation-specific. There is no universal rule for what environment variables, if any, affect them, or how.
The specific environment variables you are trying to use and the values you are setting for them indicate a UNIX-style system. You should be aware that
PATH variable sets the search path for executables, not libraries or headers.LD_LIBRARY_PATH designates extra directories for the dynamic linker's search path -- these are relevant at run time, not build time.CPLUS_INCLUDE_PATH is recognized by the GNU C++ compiler, and maybe others, for designating additional directories to search for include files. This is relevant to you for finding the Boost headers, but not the libraries. With GNU compilers, the directories listed in this variable will be searched before the standard directories.LIBRARY_PATH is recognized by the GNU linker, and possibly others, as designating additional directories to search for libraries. Like CPLUS_INCLUDE_PATH, this is relevant to you, but it does not allow you to substitute your libraries for like-named others found in one of the standard locations, because the standard directories are searched before these.Your error messages suggest that The linker is finding a mixture of Boost v1.53 and v1.64 libraries. Probably that means that the former reside in a directory that is search first -- likely a system directory such as /usr/lib -- but not all the Boost libraries you are trying to link are found there; some are found in your v1.64 installation. Given that what you've already tried does not work, there is unlikely to be any environment variable you can set to fix that. As I said, however, it's implementation-dependent, and although I suspect you're using the GNU toolchain, you haven't specified.
With the GNU toolchain, if you want the linker to search your personal Boost installation for libraries before it searches the standard directories then you'll need to instruct it specifically to do so via command-line option. As discussed in comments, you can accomplish that by adding -L/truba/home/osibliyev/boost/lib to your Automake LDADD variable.