Still with the Java testsuite failures

["Zack Weinberg" <zackw at stanford dot edu>]

I am still observing ~800 spurious failures in the Java testsuite.

This is the mainline, with Alexandre's patch for the -c -o detection
bug in libtool applied.  I do not have any version of gcj or libgcj
installed anywhere on my system.

The failures fall into two broad categories:

(1)
PASS: Array_1 compilation from bytecode
lt-Array_1: error while loading shared libraries: libgcc_s.so.0: 
	cannot load shared object file: No such file or directory
FAIL: Array_1 execution from bytecode->native test

This is the same problem the objc test suite had a couple of weeks
back.  Somewhere, LD_LIBRARY_PATH needs to be augmented with the gcc
build directory.

(2)
../libtool --tag=GCJ --mode=link ../../../gcc/gcj -B../../../gcc/
   -B../ G19990301_01.class foo.class ../libgcj.la
   ../../boehm-gc/libgcjgc.la ../../zlib/libzgcj.la --main=G19990301_01
   -g -L../.libs -L../../boehm-gc/.libs -L../../zlib/.libs -lm -o
   G19990301_01 -v
../../../gcc/gcj -B../../../gcc/ -B../ G19990301_01.class foo.class
   --main=G19990301_01 -g -o .libs/G19990301_01 -v ../.libs/libgcj.so
   -L/home/zack/src/b/gcc_vanilla/i686-pc-linux-gnu/libjava
   -L/home/zack/src/b/gcc_vanilla/i686-pc-linux-gnu/libjava/../libstdc++-v3/libsupc++
   -ldl ../../boehm-gc/.libs/libgcjgc.so ../../zlib/.libs/libzgcj.so
   -L/home/zack/src/b/gcc_vanilla/i686-pc-linux-gnu/libjava/.libs
   -L/home/zack/src/b/gcc_vanilla/i686-pc-linux-gnu/boehm-gc/.libs
   -L/home/zack/src/b/gcc_vanilla/i686-pc-linux-gnu/zlib/.libs -lm
   -Wl,--rpath -Wl,/work/inst/lib
Reading specs from ../../../gcc/specs
Reading specs from /home/zack/src/b/gcc_vanilla/i686-pc-linux-gnu/libjava/libgcj.spec
rename spec lib to liborig
rename spec startfile to startfileorig
Configured with: ../../gcc_vanilla/configure --without-included-gettext --prefix=/work/inst
gcc version 3.1 20010315 (experimental)
 ../../../gcc/jc1 ../.libs/libgcj.so -fno-use-divide-subroutine -fuse-boehm-gc -fasynchronous-exceptions -quiet -dumpbase libgcj.so -g -version -ffilelist-file -o /tmp/cco9mrIP.s
GNU Java version 3.1 20010315 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.1 20010315 (experimental).
jc1: No such file or directory: can't open ^?ELF^A^A^A

This looks like a serious driver or spec bug.  It's trying to run jc1
on ELF shared objects, instead of the .class files as would be
expected.  jc1 is then (I think) interpreting them as lists of files
to compile - '^?ELF^A^A^A' is the first seven bytes of an ELF object
on this system, and the eighth is a nul.

I think it only happens when there's more than one .class file on the
command line.

There tend to be bytecode verifier errors or segfaults along with
this.  Not sure why, but one definite possibility is that it's feeding
ELF objects to the verifier.

zw