Bug 6819

Summary: duplicate class registration bug
Product: gcc Reporter: oskar
Component: libgcjAssignee: Not yet assigned to anyone <unassigned>
Severity: normal CC: bryce, gcc-bugs, java-prs
Priority: P3    
Version: 3.1   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2005-09-10 19:33:08
Bug Depends on: 12725    
Bug Blocks:    

Description oskar 2002-05-26 08:36:00 UTC
This is probably an old and known problem:

If you compile a class that also exists in libgcj into an executable, you'll get an error like this when running the executable:

libgcj failure: Duplicate class registration: org.w3c.dom.Attr

Note that the same problem does not occur when running the class with gij.

This (probably) means that if you compile your program with a version of libgcj which doesn't contain class Y, it is not possible to run this program with a newer version of libgcj which does contain class Y. (Granted class Y is compiled into the program in the first place.)

Comment 1 Bryce McKinlay 2002-05-27 16:03:41 UTC
From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
To: gcc-gnats@gcc.gnu.org
Subject: Re: libgcj/6819: duplicate class registration bug
Date: Mon, 27 May 2002 16:03:41 +1200

 Yes, this is a well known issue. The problem is that if we have 
 duplicated symbols (ie the same symbol representing both old and new 
 versions of a class), it is quite non-deterministic (or at least 
 non-portable) which of them will actually be found and used at runtime 
 by the linker.
 This should be fixable in conjunction with implementing a weaker linking 
 model - this is also needed for strict adherance to Java's binary 
 compatibility spec, and would allow us to do cool things like link 
 compiled classes against interpreted class files, etc.
Comment 2 Dara Hazeghi 2003-05-27 05:49:21 UTC

A good many things have changed since gcc 3.1. Can you confirm whether this bug is still current 
with gcc 3.3? Thanks,

Comment 3 Andrew Pinski 2003-05-27 14:51:01 UTC
See Dara's question.  But I think this is still a problem, Can you provide a self contained 
example of this, I think I know how to repoduce this but It would be nice for other people.
Comment 4 oskar 2003-05-28 12:57:28 UTC
It seems this bug is fixed in 3.3.

echo >Demo.java 'class Demo { public static void main(String[] args) { File f =
new File(); } }'
mkdir java java/io
echo >java/io/File.java 'public class File { public File() {
System.out.println("hello"); } }'
gcj-3.3 -o Demo java/io/File.java Demo.java --main=Demo

That should print 'hello', which it does with 3.3. I haven't tested 3.1 or
earlier with this example though. 
Comment 5 oskar 2003-05-28 13:00:56 UTC
I'm sorry, this bug still exists. I forgot to include 'package java.io;' in the
File.java source file in the test above. When you do, you will still get this
error at runtime:

libgcj failure: Duplicate class registration: java.io.File
Comment 6 Dara Hazeghi 2003-06-02 03:06:02 UTC
Thanks for the confirmation. Sorry that this one still isn't fixed :-(
Comment 7 Tom Tromey 2003-11-10 07:06:17 UTC
This problem will be fixed by the binary compatibility ABI.
I've marked the dependency on the BC-ABI tracking bug.
Comment 8 Andrew Pinski 2016-09-30 22:50:04 UTC
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.