If you don't have a previous incarnation of GCJ installed...

Fri Mar 9 01:22:00 GMT 2001

... and you try to build libjava, using the just-built compiler, the
configure script gets really confused. See, gcj won't compile
anything at all unless it is told where to find an existing libjava.
The libjava source tree suffices - almost (see below) and the Makefile
has logic to point it there, but ltconfig doesn't. So you get things
like this:
ltconfig:792: checking if /home/zack/src/b/gcc_vanilla/gcc/gcj
	 supports -c -o file.o
ltconfig:793: /home/zack/src/b/gcc_vanilla/gcc/gcj 
	-B/home/zack/src/b/gcc_vanilla/i686-pc-linux-gnu/libjava/
	 -B/home/zack/src/b/gcc_vanilla/gcc/ -c -g -O2 -o out/conftest2.o
	 conftest.java 1>&5
conftest.java:0: Can't find default package `java.lang'.
Check the CLASSPATH environment variable and the access to the archives.
conftest.java:0: confused by earlier errors, bailing out
This causes ltconfig to conclude that no, gcj doesn't support -c with
-o. So libtool tries to work around that with mv. That in turn
causes ~500 spurious testsuite failures, because the mv from fileutils
4.0 rejects an attempt to move a file onto itself.
Sticking -fclasspath=${srcdir} into $GCJ in configure.in isn't good
enough, because gnu/classpath/Configuration.java doesn't exist yet,
and it tries to read that. I tried to fake one and got into a
situation where gcj still didn't work from ltconfig, but the exact
same command executed by hand worked. At that point I gave up.
zw