This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: classpath-tools.jar
- From: Tom Tromey <tromey at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: GCJ <java at gcc dot gnu dot org>
- Date: 31 Jan 2007 15:05:26 -0700
- Subject: Re: classpath-tools.jar
- References: <17856.32643.234003.34938@zebedee.pink>
- Reply-to: tromey at redhat dot com
>>>>> "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