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

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

... 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