Re: make dist fixes
Hi Brian, On Fri, 2002-02-08 at 06:00, Brian Jones wrote: For me, make distcheck fails for unknown reasons at this time distcheck fails for me with a 'Error: files left after uninstall' since all files (classes) that where unpacked from the zip file are still in the install directory after an uninstall. That is annoying but not very bad. I've placed a pre-release file at ftp://alpha.gnu.org/gnu/classpath/classpath-0.03-pre1.tar.gz Tried it on my main development machine and compiling went all OK. But when trying out orp I got $ mains/orp/Linux/dbg/orp -swapjit 0 1 -classpath $CLASSPATH Hello Linking error: (6) while resolving method at constant pool index 33 in class gnu/java/io/encode/Encoder8859_1 Linking error: (6) while resolving method at constant pool index 33 in class gnu/java/io/encode/Encoder8859_1 Fatal error: can't compile gnu/java/io/encode/Encoder8859_1.clinit()V I am going to check what went wrong. When I tried the build on a machine without jikes and zip installed something went wrong. The build automatically used gcj to compile the classes (good). But since $(ZIP) was not defined it then gave the following error: r -D glibj.zip gnu java javax /dev/null /bin/sh: r: command not found make[1]: [glibj.zip] Error 127 (ignored) configure should complain about the absence of zip. In the time I have, I could not make it possible to include generated JNI header files, so a user would need gcjh if configuring with --enable-jni I don't think that is a very big problem. Most people that are trying Classpath now probably have gcc installed. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi, On Fri, 2002-02-08 at 15:42, Mark Wielaard wrote: $ mains/orp/Linux/dbg/orp -swapjit 0 1 -classpath $CLASSPATH Hello Linking error: (6) while resolving method at constant pool index 33 in class gnu/java/io/encode/Encoder8859_1 Linking error: (6) while resolving method at constant pool index 33 in class gnu/java/io/encode/Encoder8859_1 Fatal error: can't compile gnu/java/io/encode/Encoder8859_1.clinit()V I am going to check what went wrong. OK. Ignore me. I still had the jikes with the StringBuffer.append bug in my path. Reconfigure with jikes 1.15 and everything works. I will try the new jikes from CVS now. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi, On Fri, 2002-02-08 at 16:20, Mark Wielaard wrote: OK. Ignore me. I still had the jikes with the StringBuffer.append bug in my path. Reconfigure with jikes 1.15 and everything works. I will try the new jikes from CVS now. Same problem :( I have not yet figured out if it is a jikes compiler problem or a ORP jit problem. The StingBuffer.append() bug is gone though. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi, On Fri, 2002-02-08 at 16:43, Mark Wielaard wrote: I will try the new jikes from CVS now. Same problem :( I have not yet figured out if it is a jikes compiler problem or a ORP jit problem. The problem seems to come from the fact that jikes 1.15 (and gcj) generate things like: 1804: invokestatic #34=Method gnu.java.io.encode.EncoderEightBitLookup.loadTable ()void But jikes 1.15a (from CVS) generates: 1804: invokestatic #33=Method gnu.java.io.encode.Encoder8859_1.loadTable ()void Since loadTable() is a static method in (the superclass) EncoderEightBitLookup not in (the subclass) Encoder8859_1 it seems that jikes 1.15a generates wrong code in this case. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Actually, the bug was in jikes 1.15, and is still in the jit. JLS 13
requires that compilers emit method references relative to the class
that qualifies the method invocation, even if that class only inherits
the method. It is then up to the VM to correctly track inheritance
issues when resolving method calls. Sun's javac 1.3 also had this bug,
JDK 1.4 compiles the way jikes 1.15a does (ie. Encoder8859_1.loadTable).
It makes a difference in this example:
in A.java:
class A
{
static void m() { System.out.print(a); }
}
in B.java:
class B extends A {}
in C.java:
class C
{
public static void main(String[] args)
{
B.m();
}
}
Now, recompile B.java:
class B extends A
{
static void m() { System.out.print(b); }
}
The result of executing the (unchanged) C.class should now be b, not
a.
This is also the reason that Sun's javap program will often list null as
the method or field name for classes compiled with javac 1.4, because
they have not yet fixed javap to take inheritance into account.
Mark Wielaard wrote:
The problem seems to come from the fact that jikes 1.15 (and gcj)
generate things like:
1804: invokestatic #34=Method
gnu.java.io.encode.EncoderEightBitLookup.loadTable ()void
But jikes 1.15a (from CVS) generates:
1804: invokestatic #33=Method
gnu.java.io.encode.Encoder8859_1.loadTable ()void
Since loadTable() is a static method in (the superclass)
EncoderEightBitLookup not in (the subclass) Encoder8859_1 it seems that
jikes 1.15a generates wrong code in this case.
Cheers,
Mark
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi Eric, On Fri, 2002-02-08 at 20:14, Eric Blake wrote: Actually, the bug was in jikes 1.15, and is still in the jit. JLS 13 requires that compilers emit method references relative to the class that qualifies the method invocation, even if that class only inherits the method. It is then up to the VM to correctly track inheritance issues when resolving method calls. Sun's javac 1.3 also had this bug, JDK 1.4 compiles the way jikes 1.15a does (ie. Encoder8859_1.loadTable). That (and the example) seems to make sense. But it also means that we don't have one bug in jikes, but two bugs, one in ORP and one in gcj byte code generation. Sigh. That basicly means we don't recommend jikes 1.15a for this Classpath release and ORP 1.0.9, or we wait for a new ORP release with a fix. H. I would opt for releasing now and adding a note about this problem (with newer versions of jikes and ORP) to the README/INSTALL file. Or we could try to produce a patch for ORP, but I am not sure that is very easy. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Keep in mind that a workaround for this is to explicitly qualify the
method with the desired class (ie. the one where the method is actually
defined).
In other words, instead of
Encoder8859_1.loadTable()
in the source code, use
EncoderEightBitLookup.loadTable()
The only problem I see with this approach is if EncoderEightBitLookup is
not accessible when Encoder8859_1 is. Then an alternative workaround
would be to modify Encoder8859_1 by adding this method:
public static void loadTable() { super.loadTable(); }
I'm not familiar with the ORP code, but these workarounds shouldn't be
too hard.
Do you want me to file a PR for the gcc bug? I've yet to get a working
compile of gcj on my cygwin box, so I'm not sure how well I would do on
bug reporting.
Mark Wielaard wrote:
That (and the example) seems to make sense. But it also means that we
don't have one bug in jikes, but two bugs, one in ORP and one in gcj
byte code generation. Sigh.
That basicly means we don't recommend jikes 1.15a for this Classpath
release and ORP 1.0.9, or we wait for a new ORP release with a fix.
H. I would opt for releasing now and adding a note about this
problem (with newer versions of jikes and ORP) to the README/INSTALL
file. Or we could try to produce a patch for ORP, but I am not sure that
is very easy.
Cheers,
Mark
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi, On Sat, 2002-02-09 at 02:16, Eric Blake wrote: Keep in mind that a workaround for this is to explicitly qualify the method with the desired class (ie. the one where the method is actually defined). In other words, instead of Encoder8859_1.loadTable() in the source code, use EncoderEightBitLookup.loadTable() O boy, a workaround that can be put in the Classpath code. And it works! (for HelloWorld, I still haven't setup Mauve for more extensive testing). Great! I can checkin that workaround for the encode/decode code. What are your thoughts on jikes 1.15a (CVS) is it better then jikes 1.15? Do you want to make a (semi) release of that code? I'm not familiar with the ORP code, but these workarounds shouldn't be too hard. I did look briefly at the ORP code and it isn't that dificult. The code can be found in common/class_loader/Resolve.cpp and Class.cpp. I think I understand what goes wrong (the method gets looked up by going up in the class hierarchy, but then the constant pool of the original referenced class seems to be used) but I haven't actually tried to change/fix the code. Do you want me to file a PR for the gcc bug? I've yet to get a working compile of gcj on my cygwin box, so I'm not sure how well I would do on bug reporting. I think your explanation plus example is good enough to put in the bug database (maybe with a reference to the email that showed the bytecode). That way the issue will not be forgotten. I am afraid that gcj does not yet compile on cygwin, although there is currently a lot of work done to get it to compile on Windows (if mingw is the same kind of thing as cygwin). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark That (and the example) seems to make sense. But it also means Mark that we don't have one bug in jikes, but two bugs, one in ORP Mark and one in gcj byte code generation. Sigh. If you have the time, would you mind constructing a test case so we can see if gij also has the runtime bug? I'd appreciate that. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi Brian, I am afraid I don't understand enough of automake to help. But I am currently updating the Makefile.am EXTRA_DIST java file lists. Please yell if that interferes with your work then I won't commit. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Mark Wielaard [EMAIL PROTECTED] writes: Hi Brian, I am afraid I don't understand enough of automake to help. But I am currently updating the Makefile.am EXTRA_DIST java file lists. Please yell if that interferes with your work then I won't commit. It does not interfere. Please commit the work. Thanks for doing this tedious part. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Brian Jones [EMAIL PROTECTED] writes: I just checked in a set of fixes to help get make dist to work. I've run into a problem with the generated Makefiles that comes from one of the auto* tools. Dove into automake and configure tonight and solved this little mystery. Essentially the check for what to put in @am__include@ is only done as part of something previously included only when using --enable-jni because of one of the checks for a compiler or something. I've moved the 'if' statement down a bit in configure.in to fix this. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Brian == Brian Jones [EMAIL PROTECTED] writes: I just checked in a set of fixes to help get make dist to work. I've run into a problem with the generated Makefiles that comes from one of the auto* tools. Brian Dove into automake and configure tonight and solved this little Brian mystery. Essentially the check for what to put in Brian @am__include@ is only done as part of something previously Brian included only when using --enable-jni because of one of the Brian checks for a compiler or something. I've moved the 'if' Brian statement down a bit in configure.in to fix this. Thanks for looking at this. We're aware of the problem. Every conditional you use must always be declared -- running AM_CONDITIONAL in an `if' or something in configure will (could) generate output that confuses make. In the CVS automake we've added code to check for this at configure time. We can't do a perfect job, since autoconf doesn't really know about shell flow-control, but we can detect the error when it occurs and report it to the user. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark It is missing include/jni.h.in and include/jni_md-x86-linux-gnu.h and I Mark don't know how to add them since there is some magic going on with the Mark include dir. You ought to be able to use something like this in the top-level Makefile.am: EXTRA_DIST = include/jni.h.in include/jni_md-x86-linux-gnu.h I'm a little surprised that jni.h.in isn't automatically distributed. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Tom Tromey [EMAIL PROTECTED] writes: Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark It is missing include/jni.h.in and include/jni_md-x86-linux-gnu.h and I Mark don't know how to add them since there is some magic going on with the Mark include dir. You ought to be able to use something like this in the top-level Makefile.am: EXTRA_DIST = include/jni.h.in include/jni_md-x86-linux-gnu.h I'm a little surprised that jni.h.in isn't automatically distributed. No surprise there. Fixed it tonight, but I missed Mark's message so I don't know if he is referring to CVS or to what happens when he does make dist. Anyway I'm committing my changes now. -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
The release is planned for tomorrow, but we haven't had the chance to have folks test a pre-release .tar.gz. For me, make distcheck fails for unknown reasons at this time, but I've been able to build and install and use classpath with orp from this pre-release. I've placed a pre-release file at ftp://alpha.gnu.org/gnu/classpath/classpath-0.03-pre1.tar.gz Please try it, tomorrow night I can release a final .tar after problems are fixed. In the time I have, I could not make it possible to include generated JNI header files, so a user would need gcjh if configuring with --enable-jni or for two points use the version I wrote and stuck into classpath-tools with a working VM. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
