This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Almost there...
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>
- Cc: java at gcc dot gnu dot org
- Date: Tue, 23 Jul 2002 14:55:09 +1200
- Subject: Re: Almost there...
- References: <200207221016.g6MAGb4Z014106@rzdspc1.informatik.uni-hamburg.de>
Norman Hendrich wrote:
Compiling went quite well; I actually got about 500 object files
in a few minutes with only two non AWT-related problems:
1) Some of my source files include German umlauts, but compiling with
gcj --encoding=ISO-8859-1, as posted recently on this list, worked.
Ideally, GCJ should default to the same encoding that javac does on any
given system. IIRC the reason why it doesnt is that the system's iconv
implementation, used by GCJ, sometimes doesn't support the conversions
we need. Javac and the JDK use their own character converter
implementations instead of relying on the system's iconv. The proposed
solution is to put the libiconv library in the GCC tree and use it, at
least on the platforms where the system iconv doesn't do everything we
need.
2) GCJ doesn't like double constants like "0E-9" (jikes and javac do).
Could you please enter a GNATS PR for this one?
I tried to "borrow" the missing classes (java.awt.Stroke,
java.awt.BasicStroke, java.awt.geom.GeneralPath) from the JDK.
But that only leads to gcj internal compiler errors.
FYI, I have already merged all of classpath's AWT/Java2D/Swing and some
other bits into my local tree, which includes these classes.
Unfortunately a compiler bug needs to be fixed before this work can be
committed, and I havn't had much time to hack on GCJ recently. Hopefully
I'll be able to get back onto it soon.
Q1: Is there any way to convince the linker that it should produce
an executable anyway, despite missing references?
Not yet. My plan, however, is to make the object code emitted by GCJ
comply with Java's binary compatibility spec. Class and method
references will be emitted symbolically and bound at class
initialization rather than by the linker. One advantage of this is that
missing methods will cause a runtime NoSuchMethodException instead of a
link error.
Q2: Are you at all interested in a more detailed bug report against
the gcj AWT?
For AWT I suspect we're more interested in patches than bug reports ;-)
regards
Bryce.