Almost there... (episode 2)

Fri Jul 26 03:39:00 GMT 2002

Hello,
after both Bryce and Mark told me that Classpath AWT had the classes
I complained about on Monday, I tried to merge some of the Classpath
code into my gcc (3.1 release) tree. Here are the first results,
and a few more questions :-)
disclaimer: I write this while my short-term memory is still fresh. 
On the downside, I haven't reflected too much about what I am 
going to type... 
---
episode 2 of ATCW ("attack of the cursed windows"?)
With the changes outlined below, I could compile all essential classes 
from my project. I got nice gcj-compiled executables for both my jfig 
graphics editor and the hades digital logic simulator.
Unfortunately, my claim that batch-mode simulation would not use the
AWT was not correct. The simulator starts, prints the welcome message,
parses its command line options, and then dies:
"cannot load AWT Toolkit: gnu.java.awt.peer.gtk.GtkToolkit"
... <stack trace deleted>
Obviously, I forgot about static object initialization... 
I am still confident that I don't actually need any windows, just 
Toolkit and perhaps some Font initialization.
I seem to remember that there was some magic involved to getting
either the gtk or the Xlib peers built. Unfortunately, I can not
find that info neither on the GCJ help pages nor searching this list.
The most recent message I found is not very helpful and certainly
not encouraging:
 From http://gcc.gnu.org/ml/java/2002-04/msg00022.html:

 Mark> All these failures seem to be because the test tries to
 Mark> initialize a java.awt class which fails since java.awt.Toolkit
 Mark> cannot be initialized. Some tests succeed for Object, BitSet
 Mark> and Applet. So it seems we must implement more of java.awt first
 Mark> before seeing progress on this test.
 Tom> Meanwhile let's disable these tests in mauve-libgcj. Feel free to
 Tom> simply check in such a patch.
Any ideas on how to proceed? If I get past the Toolkit issue,
the real debugging can begin :-)
- Norman
--- AWT nitpicks ---
* This is the first time ever that I tried to add new classes to the
 gcc/gcj build process. Is it correct to just add new class entries
 in libjava/Makefile.in and then rebuild?
* I added the following classes from Classpath 
 java.awt.BasicStroke
 java.awt.TexturePaint
 java.awt.geom.GeneralPath
 java.awt.image.MemoryImageSource

* I then enabled the corresponding getters/setters and stub methods in 
 java.awt.Graphics
 java.awt.Graphics2D
 gnu.awt.j2d.Graphics2DImpl

* gcj internal compiler error when compiling the new (Classpath)
 java.awt.image.MemoryImageSource at -O2

 compiling without -O2 works...
 removed all implementation from MemoryImageSource
* no java.awt.GridBagLayout 
 I took the one from Classpath, but GridBagConstraints from gcj.

* java.awt.Color does not implement java.awt.Paint
 I uncommented the one call to Graphics.setPaint( Color ) from my code.
* missing method showStatus() in java.applet.Applet
 workaround: just compile the applications, not the applets...
* missing methods getStringBounds() in java.awt.FontMetrics
 (missing both from GCJ and Classpath; however, Rectangle2D is 
 available by now, so stub methods should be easy to add)

 As it turned out, I only used that during debugging my classes,
 so I could remove those calls...

* added java.awt.print.* classes from Classpath, editing Makefile.in
 Compiling works, but the new classes are not included in libgcj.so...
 What happens?

 changed my CLASSPATH, so that gcj could find the java/awt/print/*.o
 files directly from the build tree instead of the libgcj.so

--- compiler problems ---

* three classes in my code use a GIFEncoder.GIFEncoder package which I 
 found a long time ago on Gamelan.

 gcj fails to compile those classes both from source and from classes.
 Given the GIF licensing issues, I should probably not send you those
 offending classes, or should I?

 removed calls to GIFEncoder from my app...