classpath-tools.jar

[Tom Tromey]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> We need to make very sure that the gcj tools don't pick up random jar
Andrew> files from /usr/share/java: perhaps by binding in a hard CLASSPATH.
Andrew> Perhaps we should install old classpath-tools.jar in a special place
Andrew> so that it gets found first.  But we really must do something because
Andrew> this prevents gcj from building.

I couldn't reproduce this.  I installed Jakub's test RPMs on my FC6
box, made a dummy /usr/share/java/classpath-tools.jar (I just copied
some random jar which I know does not have the right code in it), and
ran gjar.  It works fine.

libgcj should not use or refer to classpath-tools.jar at all.
Instead the tool code is all compiled (BC ABI) into libgcj-tools.so.
Then each tool executable is linked against that, each with a
different --main.  (This may not be the very best approach for
java-gcj-compat.  For that we may also need to register the classes
from libgcj-tools-$version.jar into the class map .db.)

As a last try I ran strings on my gjar and my libgcj-tools.so.
Neither mentions "classpath-tools".

Hmm... I wonder if somehow you have tools executables from
classpath/tools installed.  We should not be installing those but we
don't seem to disable the Makefile bits.

Tom