Thu Feb 1 10:26:00 GMT 2007
Tom Tromey writes:
> >>>>> "Andrew" == Andrew Haley <email@example.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.
* 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?
More information about the Java