On Wed, 11 Jun 2008 19:28:25 +0100, Andrew Haley wrote:
>> 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.
>
> It's because you have put the Boost library in gcc 4.1's own library
> directory. gcc 4.1 will search that directory before any paths in
> environment variables.
Even with the boost not in /usr/lib64 but in my custom directory (/cvos/
shared/apps/boost/gcc-4.1/1.0.35) gcc 4.1 will pick it up fine, preferring
it over the boost in /usr/lib, without -L on the condition that I have set
LIBRARY_PATH and LD_LIBRARY_PATH to that custom directory
$ gcc -v -o test test.cpp -lboost_regex
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-
checking=release --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c+
+,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --
enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --
with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1plus -quiet -v -
D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic -auxbase
test -version -o /tmp/ccorv0m2.s
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-
linux/4.1.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/cvos/shared/apps/boost/gcc-4.1/1.35.0/include
/cvos/shared/apps/openmpi/gcc/64/1.2.2/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/
x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/
backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
/usr/include
End of search list.
GNU C++ version 4.1.2 20070626 (Red Hat 4.1.2-14) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-14).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0c8f7bd7e61623962867833d3a2a3ac2
as -V -Qy -o /tmp/ccvUoYUQ.o /tmp/ccorv0m2.s
GNU assembler version 2.17.50.0.6-5.el5 (x86_64-redhat-linux) using BFD
version 2.17.50.0.6-5.el5 20061020
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/collect2 --eh-frame-hdr -m
elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
test /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o /usr/
lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/
x86_64-redhat-linux/4.1.2/crtbegin.o -L/cvos/shared/apps/boost/
gcc-4.1/1.35.0/lib -L/cvos/shared/apps/openmpi/gcc/64/1.2.2/lib64/../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-
linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/
lib/../lib64 -L/usr/lib/../lib64 /tmp/ccvUoYUQ.o -lboost_regex -lgcc --as-
needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-
needed /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-
redhat-linux/4.1.2/../../../../lib64/crtn.o
Here With gcc 4.1 the -L/cvos/shared/apps/boost/gcc-4.1/1.35.0/lib comes
before the -L/usr/lib/../lib64 in the generated command, while with gcc
4.2 it comes after. But why it does this?
About the relevance of $LIBRARY_PATH with gcc-4.1:
$ echo $LD_LIBRARY_PATH
/cvos/shared/apps/boost/gcc-4.1/1.35.0/lib:/cvos/shared/apps/sge/6.1/lib/
lx26-amd64
$ echo $LIBRARY_PATH
/cvos/shared/apps/boost/gcc-4.1/1.35.0/lib
$ g++ -o test test.cpp -lboost_regex
$ ldd test | grep boost
libboost_regex.so.1.35.0 => /cvos/shared/apps/boost/gcc-4.1/1.35.0/
lib/libboost_regex.so.1.35.0 (0x00007fdc8269d000)
$ export LIBRARY_PATH=""
$ g++ -o test test.cpp -lboost_regex
$ ldd test | grep boost
libboost_regex.so.2 => /usr/lib64/libboost_regex.so.2
(0x00007fff74e4a000)
--
Frederik
