Almost there... (episode 2)

[Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>]

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