GCC is not linking library to a non-default path!

Question

I have boost C++ libraries already installed on my Fedora10 machine but I want to use a newer version that I keep at some location in my home folder. I want g++ to use include and library files from my home folder location instead of default (/usr/include and /usr/lib64).

For that matter, I also have declared CPLUS_INCLUDE_PATH and LIBRARY_PATH environment variables in my ~/.bashrc file as explained here. http://www.network-theory.co.uk/docs/gccintro/gccintro_23.html

Now when I run,

g++ -o hello.so -fPIC hello.cpp -shared -lboost_python

The preprocessor uses include files from my home folder location, overriding the default location (as it should, because CPLUS_INCLUDE_PATH has a higher precedence in the search path). But the linker does not seem to follow the same precedence rule. It always uses libboost_python.so from the default location /usr/lib64 instead of first searching LIBRARY_PATH. It only links to the libboost_python.so library in my home folder when I explicitly specify with -L switch. This is really inconvinient. Am I missing something? Please help!

Answer 1

The -L switch is the standard way of telling the compiler where to find the libraries. Write a makefile that builds your compiler/linker switches - you'll find it's worth investing your time. You can do something like:

MY_LIBPATH += -L$(BOOST_LIB_PATH)
MY_INCPATH += -I$(BOOST_INC_PATH)
hello.so: hello.cpp
    g++ -o $@ -fPIC $(MY_INCPATH) $(MY_LIBPATH) hello.cpp -shared -lboost_python

And then you can control this via environment (of course there could be many variations on how to structure the makefile.)

Answer 2

Thanks for your suggestion. I already knew about the Makefile solution but was just too lazy to use. Anyway the point of my question is, why is g++ showing such anomalous behaviour in the first place, or am I doing something incorrect?