Almost there...

[Norman Hendrich]

Hello all,

<intro>
After some time of just reading about gcj, I decided that it was time
to play with it again. I downloaded the gcc-3.1 release; configuring,
building, and installing went fine (SuSE Linux on x86).

I then went on to compile a few hundred classes from my discrete event
simulation framework. Despite the still untested AWT in gcj, I hoped
that I could compile most classes and run simulations in batch-mode
without the GUI. This should make for some interesting performance
comparisons with the JDKs, especially due to extremely high stress 
for the  garbage-collector...
</intro>


<buglets>
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.
   
   I think this should go onto the GCJ FAQ web page.
   
   
2) GCJ doesn't like double constants like "0E-9" (jikes and javac do).

   public class GcjNumberParserProblem {
     public static void main( String argv[] ) {
       float f = 0E-6F;
       double d = 0E-9;
       System.out.println( "" + f + " " + d  );
     }
   }
   
   (The idea for writing the numbers that way was to indicate that
   typical values for a parameter were in the nanoseconds range).
</buglets>


<awt>
Next I tried to compile the GUI stuff to ".o" files. Unfortunately
it turned out that some of my base classes refer to Java2D stuff
still missing from libjava AWT. This in turn means that due to 
about five missing stub methods, I cannot compile those classes,
which explode to "2713 undefined reference" errors when trying to 
link everything into the simulator executable :-( 

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.

I also tried to edit java.awt.Graphics2D and to write my own stub
implementations of Stroke and BasicStroke, but now the GCJ make
process detects that gnu.awt.Graphics2DImpl is no longer implementing
all abstract methods...  as my code cannot go into GCJ for 
missing FSF paperwork anyway, I decided to stop here.
</awt>



two dumb questions:

Q1: Is there any way to convince the linker that it should produce
    an executable anyway, despite missing references?  
   
    I am quite confident that all classes and methods actually used 
    during  batch-mode simulation are there.
    
Q2: Are you at all interested in a more detailed bug report against 
    the gcj AWT? 

- Norman