This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Bug in multifile operation?
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: Per Bothner <per at bothner dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>, GCJ <java at gcc dot gnu dot org>
- Date: Fri, 06 May 2005 18:32:27 +0200
- Subject: Bug in multifile operation?
- References: <426EFE00.3060903@3am-software.com> <20050427025707.GA20956@nevyn.them.org> <20050427053042.GA1317@redhat.com> <426F2611.7060801@3am-software.com> <426FD0DC.50601@codesourcery.com> <427962FC.5000305@bothner.com> <4279C184.6050909@gmail.com> <m3oebpu47j.fsf@localhost.localdomain> <427B1AA2.40209@lu.unisi.ch> <427B8DA2.5020001@bothner.com>
Per Bothner wrote:
Paolo Bonzini wrote: >> But what Per is talking about is how .o files
are built. This change
would probably not be very difficult fwiw; we already have done this
in a place or two where we've needed BC ABI support.
As long as libtool supports it, it should not be very difficult indeed.
It semi-supports it.
With @aaa.list it supports it, it seems. I made a patch, but it fails
because of a bug. It is enough to supply these two files together to jc1
package java.awt;
import java.util.EventObject;
public abstract class AWTEvent extends EventObject {}
package java.awt;
import java.awt.event.KeyEvent;
public class B {
Object[] o = KeyEvent.class.getFields();
}
I'm tracking the failure, so far it seems that, in find_in_imports for
java.awt.event.KeyEvent, there's already something different in the
IDENTIFIER_CLASS_VALUE for KeyEvent. But I have not understood where it
is set. :-(
Paolo