libjava testsuite problem under i686-pc-linux-gnu

Sat May 26 13:39:00 GMT 2001

> > Also noticed testsuite applications appear to link with static libgcc.a.
>> Now you've got me really baffled. Is it linking with libgcc_s.so.0
> *and* libgcc.a? If so, is it including anything from thaht library in
> the executable?

I think I may have been confusing things. The testsuites for various
GCC libraries have similar problems but the details seem to differ.
I looked in detail at the linking of Array_1 in libjava. It fails
with the error:
dave@hiamlx:~/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite > ./Array_1lt-Array_1: error in loading shared libraries: /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs/libzgcj.so.0: symbol __deregister_frame_info_bases, version GCC_3.0 not defined in file libgcc_s.so.0 with link time reference
The selection of libgcc seemed ok both for the shared libraries which it
uses or in the linking of Array_1 itself.
If I replace the old libgcc_s.so.0 in the install directory with the new
libgcc_s.so in the build directory the test no longer fails. It is clear
that libgcc_s in the install directory is being used in preference to
is the link output for Array_1. Don't know about the other shared
libraries but these also could be from the install directory.
The command to build Array_1 is:
spawn /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /home/dave/gnu/gcc-3.0/objdir/gcc/gcj -B/home/dave/gnu/gcc-3.0/objdir/gcc/ --encoding=UTF-8 -B/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite/../ /home/dave/gnu/gcc-3.0/libjava/testsuite/libjava.lang/Array_1.java /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/libgcj.la /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//boehm-gc/libgcjgc.la /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/libzgcj.la --main=Array_1 -g -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/.libs -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//boehm-gc/.libs -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs -lm -o /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite/Array_1
Libtool turns this into:
/home/dave/gnu/gcc-3.0/objdir/gcc/gcj -B/home/dave/gnu/gcc-3.0/objdir/gcc/ --encoding=UTF-8 -B/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite/../ /home/dave/gnu/gcc-3.0/libjava/testsuite/libjava.lang/Array_1.java --main=Array_1 -g -o /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite/.libs/Array_1 /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/.libs/libgcj.so -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava -ldl /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//boehm-gc/.libs/libgcjgc.so -lpthread /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs/libzgcj.so -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/.libs -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//boehm-gc/.libs -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs -lm -v -Wl, -rpath -Wl,/usr/local/lib
This gives the following dependencies in the executable:
dave@hiamlx:~/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite > ldd .libs
/Array_1
 libgcj.so.2 => /usr/local/lib/libgcj.so.2 (0x40015000)
	libdl.so.2 => /lib/libdl.so.2 (0x40467000)
	libgcjgc.so.1 => /usr/local/lib/libgcjgc.so.1 (0x4046a000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x40489000)
	libzgcj.so.0 => /usr/local/lib/libzgcj.so.0 (0x4049c000)
	libm.so.6 => /lib/libm.so.6 (0x404aa000)
	libgcc_s.so.0 => /usr/local/lib/libgcc_s.so.0 (0x404c7000)
	libc.so.6 => /lib/libc.so.6 (0x404d1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
These look ok after libraries are installed.
Ah, I see the problem. It's the relink command in Array_1. We have
the following dependencies pre-install:
dave@hiamlx:~/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite > ldd .libs
/lt-Array_1
 libgcj.so.2 => /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/.libs/libgcj.so.2 (0x40015000)
	libdl.so.2 => /lib/libdl.so.2 (0x40467000)
	libgcjgc.so.1 => /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//boehm-gc/.libs/libgcjgc.so.1 (0x4046a000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x4048a000)
	libzgcj.so.0 => /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs/libzgcj.so.0 (0x4049c000)
	libm.so.6 => /lib/libm.so.6 (0x404aa000)
	libgcc_s.so.0 => /usr/local/lib/libgcc_s.so.0 (0x404c7000)
	libc.so.6 => /lib/libc.so.6 (0x404d1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
This is how a relink is done:
/home/dave/gnu/gcc-3.0/objdir/gcc/gcj -B/home/dave/gnu/gcc-3.0/objdir/gcc/ --encoding=UTF-8 -B/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite/../ /home/dave/gnu/gcc-3.0/libjava/testsuite/libjava.lang/Array_1.java --main=Array_1 -g -o /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava/testsuite/.libs/20712-lt-Array_1 -Wl,--verbose /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/.libs/libgcj.so -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu/libjava -ldl /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//boehm-gc/.libs/libgcjgc.so -lpthread /home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs/libzgcj.so -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/.libs -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//boehm-gc/.libs -L/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs -lm -Wl,--rpath -Wl,/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//libjava/.libs -Wl,--rpath -Wl,/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//bo!
ehm-gc/.libs -Wl,--rpath -Wl,/home/dave/gnu/gcc-3.0/objdir/i686-pc-linux-gnu//zlib/.libs -Wl,--rpath -Wl,/usr/local/lib
There is no `rpath' for `/home/dave/gnu/gcc-3.0/objdir/gcc/'. Thus, even
though ld finds libgcc in this directory, the runtime location is set to
`/usr/local/lib'.
This suggests that libtool should look at `-B' options as well as `-L'
options when it generates `rpath' options in the preinstall case.
Dave
-- 
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)