bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

problem linking c++ programs


From: Thomas Koeller
Subject: problem linking c++ programs
Date: Thu, 16 Nov 2006 22:42:28 +0100
User-agent: KMail/1.9.5

Hi,

I am encountering difficulties when linking c++ programs that
use libstdc++.so.

I am on a x86_64-pc-linux-gnu system using gcc-4.1.1 and
binutils-2.17. These tools are installed in /usr/gcc. The
system is self-maintained (no distribution). The compiler
is bi-arch (i686/x86_64) and hence has a set of 64-bit
libraries installed in /usr/gcc/lib64 and one of 32-bit
libraries in /usr/gcc/lib.

Until recently, I have been using libtool-1.5.22, which
apparently had a problem with this setup. Running 'make check'
after building it gave errors, like so:

=== Running tagdemo-make.test
Making in ../tagdemo
make[3]: Entering directory `/home/thomas/build64/libtool-1.5.22/tagdemo'
/bin/sh ./libtool --tag=CXX   --mode=link /usr/gcc/bin/g++ -march=athlon64  
-pipe -O3 -fomit-frame-pointer -no-undefined  -o 
libbaz.la -rpath /home/thomas/build64/libtool-1.5.22/tests/_inst/lib baz.lo 
libfoo.la
/usr/gcc/bin/g++ -march=athlon64 -shared -nostdlib /usr/lib/../lib64/crti.o 
/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/crtbeginS.o  .libs/baz.o 
-Wl,--whole-archive ./.libs/libfoo.a -Wl,--no-whole-archive  -Wl,--rpath 
-Wl,/usr/gcc/lib/../lib -Wl,--rpath -Wl,/usr/gcc/lib/../lib 
-L/home/thomas/build64/gcc-4.1.1/x86_64-unknown-linux-gnu/32/libstdc++-v3/src 
-L/home/thomas/build64/gcc-4.1.1/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
 -L/home/thomas/build64/gcc-4.1.1/./gcc/32 
-L/usr/gcc/x86_64-unknown-linux-gnu/bin -L/usr/gcc/x86_64-unknown-linux-gnu/lib 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/32 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86_64-unknown-linux-gnu/lib/../lib
 -L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib 
-L/lib/../lib -L/usr/lib/../lib 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86_64-unknown-linux-gnu/lib
 -L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib64 
-L/lib/../lib64 -L/usr/lib/../lib64 /usr/gcc/lib/../lib/libstdc++.so -lm -lc 
-lgcc_s /usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/crtendS.o 
/usr/lib/../lib64/crtn.o  -march=athlon64 -Wl,-soname -Wl,libbaz.so.0 -o 
.libs/libbaz.so.0.0.0
/usr/gcc/lib/../lib/libstdc++.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[3]: *** [libbaz.la] Error 1
make[3]: Leaving directory `/home/thomas/build64/libtool-1.5.22/tagdemo'
FAIL: tagdemo-make.test

Obviously, libtool tried to link the 64-bit program with the 32-bit
version of libstdc++.so. So I got the libtool-1.5.23a snapshot of
today (2006-11-16). With this, 'make check' succeeds, however, when
linking real programs, the problem shows up again (the example below
has been generated by building tiff-3.8.2):

make[2]: Entering directory `/home/thomas/build64/tiff-3.8.2/libtiff'
/bin/sh ../libtool --tag=CXX --mode=link /usr/gcc/bin/g++ -march=athlon64  
-pipe -O3 -fomit-frame-pointer   -o 
libtiffxx.la -rpath /usr/lib64 -no-undefined -version-number 3:8:2  
tif_stream.lo ../libtiff/libtiff.la ../port/libport.la -ljpeg -lz -lm -lc
libtool: 
link: /usr/gcc/bin/g++ -march=athlon64 -shared -nostdlib 
/usr/lib/../lib64/crti.o 
/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/crtbeginS.o  .libs/tif_stream.o 
 -Wl,--whole-archive ../port/.libs/libport.a -Wl,--no-whole-archive  -Wl,-rpath 
-Wl,/home/thomas/build64/tiff-3.8.2/libtiff/.libs -Wl,-rpath 
-Wl,/usr/gcc/lib/../lib -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath 
-Wl,/usr/gcc/lib/../lib ../libtiff/.libs/libtiff.so -ljpeg -lz 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86_64-unknown-linux-gnu/lib
 -L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib64 
-L/lib/../lib64 -L/usr/lib/../lib64 /usr/gcc/lib/../lib/libstdc++.so 
-L/home/thomas/build64/gcc-4.1.1/x86_64-unknown-linux-gnu/32/libstdc++-v3/src 
-L/home/thomas/build64/gcc-4.1.1/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
 -L/home/thomas/build64/gcc-4.1.1/./gcc/32 
-L/usr/gcc/x86_64-unknown-linux-gnu/bin -L/usr/gcc/x86_64-unknown-linux-gnu/lib 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/32 
-L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86_64-unknown-linux-gnu/lib/../lib
 -L/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib 
-L/lib/../lib -L/usr/lib/../lib -lm -lc -lgcc_s 
/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/crtendS.o 
/usr/lib/../lib64/crtn.o  -march=athlon64       -Wl,-soname -Wl,libtiffxx.so.3 
-o .libs/libtiffxx.so.3.8.2
/usr/gcc/lib/../lib/libstdc++.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[2]: *** [libtiffxx.la] Error 1
make[2]: Leaving directory `/home/thomas/build64/tiff-3.8.2/libtiff'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/thomas/build64/tiff-3.8.2/libtiff'
make: *** [all-recursive] Error 1

Again, it tried to use the 32-bit libstdc++.so in a 64-bit link.
I have been able to find a workaround (setting LDFLAGS="-L/usr/gcc/lib64"
in the environment before invoking configure), but I have no clue as to
what is wrong here. GCC certainly gets it right:

bash-3.1$ g++ -print-file-name=libstdc++.so
/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib64/libstdc++.so
bash-3.1$ g++ -m64 -print-file-name=libstdc++.so
/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib64/libstdc++.so
bash-3.1$ g++ -m32 -print-file-name=libstdc++.so
/usr/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib/libstdc++.so

Can anybody help?

Thomas
-- 
Thomas Koeller
thomas at koeller dot dyndns dot org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]