Bug 6819 - duplicate class registration bug
Summary: duplicate class registration bug
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 3.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 12725
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-26 08:36 UTC by oskar
Modified: 2016-09-30 22:50 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-09-10 19:33:08


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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
Aborted

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.)

Release:
3.1
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
Cc:  
Subject: Re: libgcj/6819: duplicate class registration bug
Date: Mon, 27 May 2002 16:03:41 +1200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6819
 
 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.
 
 Bryce.
Comment 2 Dara Hazeghi 2003-05-27 05:49:21 UTC
Hello,

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

Dara
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
./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
Aborted
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.