A few months ago I ran into an odd problem when building my code base on a remote HPC cluster. This seems to have happened when I changed compiler from GCC 4.1 to 4.3 (the cluster is set up in such a way that various compilers are installed and one can choose between them by enabling different modules). Since that move, I was facing a problem linking with boost_program_options. Since the required boost version was not installed system-wide, I manually downloaded, compiled, and installed the required boost version in my home directory.
For reference, the fundamental problem I was having involved a lot of ‘undefined reference’ errors with respect to boost::program_options fields and methods when linking my object code. The odd thing was that I was including the corresponding library in my linker (with the usual -lboost_program_options). In the end I found what the problem was, and figured out an ugly work-around, as follows.
Let’s start first with the explanation of how this problem comes into being. GCC is supposed to look for linked libraries in this order:
- paths supplied by -L in the command line (I use these for the libraries in my own code base)
- paths from the user’s LIBRARY_PATH (I use this for specifying the local boost install path, under ~/lib)
- other system dirs
The trouble is that on 64-bit machines, gcc will silently pre-pend the complete list above with all entries appended with ../lib64. Unfortunately this means that for example /lib/../lib64, from point 3 above (after appending ../lib64), will come before the plain paths from point 2 above! This is undeniably bad, and at the very least counter-intuitive, because unspecified system dirs will take priority over user-specified dirs. I wonder who dreamed up this hack!
Unfortunately, there does not seem to be a switch to disable this. The work-around is to locally create a symlink named lib64 for the paths of point 2. For point 1 in my case it’s not needed only because there cannot be a name conflict for the libraries I’m linking with. Otherwise the same applies.
This took me a whole afternoon to figure out, and recently caused the same problem to one of my co-authors. Good thing he remembered my mentioning this! So I’ve finally written this down for posterity. Here’s hoping you never need this information.