We occasionally get bug reports against GNU Classpath about strange compilation errors. Kalle Olavi Niemitalo finally tracked it down. The order in which gcj -C is given source files to compile. The smallest example given was: gcj --bootclasspath '' --classpath .:vm/reference -C -d /tmp/obj java/io/ObjectInputStream.java gnu/java/io/ClassLoaderObjectInputStream.java gnu/java/rmi/server/RMIObjectInputStream.java gnu/java/rmi/RMIMarshalledObjectInputStream.java org/omg/CORBA/portable/InputStream.java Which gives lots of errors like: gnu/java/rmi/RMIMarshalledObjectInputStream.java:52: error: Class 'gnu.java.rmi.RMIMarshalledObjectInputStream' doesn't define the abstract method 'org.omg.CORBA.Object org.omg.CORBA.portable.InputStream.read_Object()' from class 'org.omg.CORBA.portable.InputStream'. This method must be defined or class 'gnu.java.rmi.RMIMarshalledObjectInputStream' must be declared abstract. public class RMIMarshalledObjectInputStream extends RMIObjectInputStream Obviously gcj somehow picked up the wrong InputStream class from the org.omg.CORBA.portable package instead of the java.io package. No compilation errors occur when changing the order of arguments to: gcj --bootclasspath '' --classpath .:vm/reference -C -d /tmp/obj org/omg/CORBA/portable/InputStream.java java/io/ObjectInputStream.java gnu/java/io/ClassLoaderObjectInputStream.java gnu/java/rmi/server/RMIObjectInputStream.java gnu/java/rmi/RMIMarshalledObjectInputStream.java This is with either a GNU Classpath 0.15 release or a CVS checkout done in the top level directory. Similar bahavior in 3.3, 3.4, 4.0 and 4.1 branches: gcj (GCC) 3.3.5 (Debian 1:3.3.5-12) gcj-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12) gcj (GCC) 4.0.1 20050505 (prerelease) gcj (GCC) 4.1.0 20050501 (experimental) For GNU Classpath CVS I will "workaround" this issue by sorting the classes file list. That way at least we will get uniform bug reports not depending on the order in which find returns the source files.
I thought I saw something like this before.
> I thought I saw something like this before. You are probably refering to bug #17845 which was recently closed since it couldn't be reproduced (because I added a workaround to GNU Classpath). I cannot say with certainty that this is the same bug though. The main difference with that bug is that we have a testcase here (even though there was another workaround added to GNU Classpath CVS).
And I tracked our problems with The javax.swing.Box inner class AccessibleBox extends AccessibleAWTContainer in GNU Classpath to a similar order problem. Take the following source files: p/AClass.java :::::::::::::: package p; public class AClass { protected abstract class InnerA { protected InnerA() { } } } :::::::::::::: q/BClass.java :::::::::::::: package q; import p.*; public class BClass extends AClass { protected class InnerB extends AClass.InnerA { } } :::::::::::::: q/CClass.java :::::::::::::: package q; import p.AClass; public class CClass extends BClass { protected class InnerC extends AClass.InnerA { } } When compiled as follows all goes well: $ gcj -C p/AClass.java q/BClass.java q/CClass.java But when we change the order to: $ gcj -C p/AClass.java q/CClass.java q/BClass.java q/CClass.java:5: error: Nested class p.AClass$InnerA is protected; cannot be accessed from here. protected class InnerC extends AClass.InnerA ^ 1 error
Subject: Bug 21418 CVSROOT: /cvsroot/classpath Module name: classpath Branch: Changes by: Mark Wielaard <mark@savannah.gnu.org> 05/09/11 23:15:58 Modified files: . : ChangeLog lib : gen-classlist.sh.in Log message: * lib/gen-classlist.sh.in: Use sort -r to work around bug #21418. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4725&tr2=1.4726&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/lib/gen-classlist.sh.in.diff?tr1=1.30&tr2=1.31&r1=text&r2=text
Proposed patch: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00401.html
Subject: Bug 21418 CVSROOT: /cvs/gcc Module name: gcc Changes by: rmathew@gcc.gnu.org 2005-09-21 13:34:29 Modified files: gcc/java : ChangeLog class.c Log message: PR java/21418 * class.c (inherits_from_p): Try to lay out super class if it is not already laid out. (maybe_layout_super_class): Handle the case where SUPER_CLASS is a NULL_TREE. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1665&r2=1.1666 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&r1=1.240&r2=1.241
Fixed.
This patch should go into the 4.0 branch, once that thaws.
Subject: Bug 21418 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: bryce@gcc.gnu.org 2005-10-01 06:49:23 Modified files: gcc/java : ChangeLog class.c Log message: 2005-10-01 Ranjit Mathew <rmathew@gcc.gnu.org> PR java/21418 * class.c (inherits_from_p): Try to lay out super class if it is not already laid out. (maybe_layout_super_class): Handle the case where SUPER_CLASS is a NULL_TREE. 2005-10-01 Per Bothner <per@bothner.com> * class.c (inherits_from_p): Do load_class if needed. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1556.2.33&r2=1.1556.2.34 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.220.8.6&r2=1.220.8.7