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

Frederik Himpe fhimpe@telenet.be
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/
gcc-4.2/1.35.0/lib
>>> I'm not sure this will have any effect.
>>
>> Isn't the above necessary so that it searches for the libboost_regex.so
>> link in that directory, which would make it build at compile time
>> against libboost.so.1.35.0 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):

       LIBRARY_PATH
           The value of LIBRARY_PATH is a colon-separated list of 
directories,
           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 
using
           GCC also uses these directories when searching for ordinary
           libraries for the -l option (but directories specified with -L 
come
           first).

> 
>>>> $ 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-
gnu/4.2.4/../../../../lib64
> \ -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-
gnu/4.2.4/../../..
> \
> 
> Only if libboost_regex is not found in one of these will ld use
> `LD_LIBRARY_PATH'. 

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/libboost_regex.so 
| grep SONAME
  SONAME      libboost_regex.so.1.35.0
$ objdump -x /usr/lib64/libboost_regex.so | grep SONAME
  SONAME      libboost_regex.so.2

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 
4.3.

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?

-- 
Frederik



More information about the Gcc-help mailing list