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
