LIBRARY_PATH not used before /usr/lib anymore in gcc 4.2 and later?
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
>>> 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/
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
>>> 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/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 \
> 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/libboost_regex.so
| grep SONAME
$ objdump -x /usr/lib64/libboost_regex.so | 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
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