GCJ PPC Success and DOM

[Jim White <jim at pagesmiths dot com>]

Hi Gang.

I've finally got a GCJ to work on PPC.

The GCJ (3.3.3) in Yellow Dog Linux 4.0.1 works fine (hopefully I'll be 
able to figure out how to build 4.0 from that).  No joy yet for OS X, 
but it also occurs to me I should ask the Apple folks to include GCJ in 
OS X Tiger (or at least patch up their GCC branch to work).

Two things I had do:

Turned out easiest way to get W3C DOM compiled was to add it to Kawa's 
build (along with an --enable-w3cdom switch).  Not sure if you want to 
add it to Kawa too, but I'ld be happy to send you the patch if you like.

And what should we do about DOM Level 2 vs Level 3?  Should Kawa 
preprocess itself appropriately to support both?

In any case I got a decent handle on how the GCJ native build stuff 
works now.  I'm planning on looking into a unified build using Ant 
and/or Kawa now to eliminate the double maintenance (perhaps by 
generating the Makefile.am files).

Other thing I had to do was because I built --without-awt (YDL gtk is 
wrong version apparently) I got an exception in (compile "PrimOps.scm") 
because Scheme.getInstance() fails, so my workaround is:

Index: Scheme.java
===================================================================
RCS file: /cvs/kawa/kawa/kawa/standard/Scheme.java,v
retrieving revision 1.178
diff -u -r1.178 Scheme.java
--- Scheme.java 7 Mar 2005 08:03:38 -0000       1.178
+++ Scheme.java 23 Mar 2005 00:25:24 -0000
@@ -7,6 +7,7 @@
 import gnu.expr.*;
 import java.util.Hashtable;
 import gnu.text.SourceMessages;
+import gnu.kawa.lispexpr.LispLanguage;
 import gnu.kawa.lispexpr.*;
 import gnu.lists.FormatToConsumer;
 import gnu.kawa.functions.DisplayFormat;
@@ -531,7 +532,17 @@
       define_proc ("load-compiled", "kawa.lang.loadcompiled");
       defProcStFld("environment-bound?", "kawa.lib.misc");
       defProcStFld("scheme-implementation-version", "kawa.lib.misc");
-      defProcStFld("scheme-window", "kawa.lib.windows");
+
+      try {
+        // Skip this symbol if the class is undefined.
+        // If we leave it in then Language.getInstance blows up.
+        Class.forName("kawa.lib.windows");
+        defProcStFld("scheme-window", "kawa.lib.windows");
+      } catch (final ClassNotFoundException e) {
+        // Must not be configured for AWT.
+      }
+
+
       defSntxStFld("define-procedure", "kawa.lib.syntax");
       defProcStFld("add-procedure-properties", "kawa.lib.syntax");
       defProcStFld("make-procedure",

Is this the right thing or should there be a more general solution for 
symbols that fail (which happens later when importLocation is done in 
CommonLisp).

Jim