classpath-tools.jar

[Andrew Haley]

Tom Tromey writes:
 > >>>>> "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".

OK, I think I found the cause of the bug.  It's this:

lrwxrwxrwx 1 root root 35 Aug  8 16:02 /usr/share/java/gcj-endorsed/classpath-tools.jar -> /usr/share/java/classpath-tools.jar

It's fairly obvious why the gcj runtime should have picked up this bad
old jar, and why it would break things.

So,

  *  Thanks for looking at this.  Sorry for the noise.

  *  Was this just a one-off weirdness of my system, or might this
     happen to someone else?

Andrew.