Bug 21418 - Order of source files matters when compiling
Order of source files matters when compiling
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: java
4.1.0
: P2 normal
: 4.0.3
Assigned To: Not yet assigned to anyone
http://gcc.gnu.org/ml/java-patches/20...
: patch, rejects-valid
Depends on: 21436 21442
Blocks: 18131 24018
  Show dependency treegraph
 
Reported: 2005-05-06 14:29 UTC by Mark Wielaard
Modified: 2005-09-22 17:45 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-05-06 14:50:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Wielaard 2005-05-06 14:29:17 UTC
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.
Comment 1 Andrew Pinski 2005-05-06 14:31:35 UTC
I thought I saw something like this before.
Comment 2 Mark Wielaard 2005-05-06 14:50:23 UTC
> 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).
Comment 3 Mark Wielaard 2005-09-11 22:29:44 UTC
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
Comment 4 cvs-commit@developer.classpath.org 2005-09-11 23:36:48 UTC
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




Comment 5 Ranjit Mathew 2005-09-21 09:55:59 UTC
Proposed patch:

  http://gcc.gnu.org/ml/java-patches/2005-q3/msg00401.html
Comment 6 CVS Commits 2005-09-21 13:34:55 UTC
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

Comment 7 Andrew Pinski 2005-09-21 14:05:24 UTC
Fixed.
Comment 8 Bryce McKinlay 2005-09-22 17:45:30 UTC
This patch should go into the 4.0 branch, once that thaws.
Comment 9 CVS Commits 2005-10-01 06:49:30 UTC
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