LIBRARY_PATH not used before /usr/lib anymore in gcc 4.2 and later?

Frederik Himpe
Wed Jun 11 17:55:00 GMT 2008

On Wed, 11 Jun 2008 16:01:07 +0100, Andrew Haley wrote:

> Frederik wrote:
>> On Wed, 11 Jun 2008 14:55:54 +0100, Andrew Haley wrote:
>>> Frederik wrote:
>>>> On Wed, 11 Jun 2008 13:46:45 +0100, Andrew Haley wrote:
>>>>> What does readelf -d test say?
>>>> $ echo $LIBRARY_PATH
>>>> /cvos/shared/apps/gcc/gcc-4.2.4//lib:/cvos/shared/apps/boost/
>>> I'm not sure this will have any effect.
>> Isn't the above necessary so that it searches for the
>> link in that directory, which would make it build at compile time
>> against in my case? (Well, that's what I expected,
>> but it clearly does not do that here when using gcc 4.2 or 4.3)
> I don't think that it will have any effect at all.

Well, it should be an alternative to using the -L option. It works for 
other libraries (for which I don't have other versions installed in /usr/
lib64 though):

           The value of LIBRARY_PATH is a colon-separated list of 
           much like PATH.  When configured as a native compiler, GCC tries
           the directories thus specified when searching for special linker
           files, if it can’t find them using GCC_EXEC_PREFIX.  Linking 
           GCC also uses these directories when searching for ordinary
           libraries for the -l option (but directories specified with -L 

>>>> $ echo $LD_LIBRARY_PATH
>>>> /cvos/shared/apps/gcc/gcc-4.2.4//lib:/cvos/shared/apps/boost/
>> gcc-4.2/1.35.0/lib:/cvos/shared/apps/sge/6.1/lib/lx26-amd64
>>> This should work, though.
>>>> $ g++ -o test test.cpp -lboost_regex
>>> Use `gcc -v' here.  Let's see what that says.
> OK, here's the important part.  These are the directories that the
> linker searches first:
> -L/cvos/shared/apps/gcc/gcc-4.2.4//lib/../lib64 \
> -L/cvos/shared/apps/gcc/gcc-4.2.4/lib/gcc/x86_64-unknown-linux-gnu/4.2.4
> \
> -L/cvos/shared/apps/gcc/gcc-4.2.4/lib/gcc/x86_64-unknown-linux-
> \ -L/lib/../lib64 \
> -L/usr/lib/../lib64 \
> -L/cvos/shared/apps/gcc/gcc-4.2.4//lib \
> -L/cvos/shared/apps/boost/gcc-4.2/1.35.0/lib \
> -L/cvos/shared/apps/gcc/gcc-4.2.4/lib/gcc/x86_64-unknown-linux-
> \
> Only if libboost_regex is not found in one of these will ld use

AFAIK, you are talking here about runtime linking, while my problem is 
during building already: it builds against a different soname:

$ objdump -x /cvos/shared/apps/boost/gcc-4.2/1.35.0/lib/ 
| grep SONAME
$ objdump -x /usr/lib64/ | grep SONAME

Also when using LD_LIBRARY_PATH for runtime linking, it does look first in 
these directories before looking into /usr/lib64. gcc 4.1 clearly does the 
same at build time with LIBRARY_PATH, but not my self compiled gcc 4.2 and 

If you want to make sure that your libboost_regex is
> used, either put it in one of these directories or specify -L
> explicitly.

That's indeed a workaround. Still I don't understand why I would need this 
for gcc 4.2 and 4.3, but not for gcc 4.1. A shot in the dark: maybe gcc >= 
4.2 tries to be smart and thinks that it should not build against soname 
1.35.0 as it's smaller than 2?


More information about the Gcc-help mailing list