Hi Francesco,

On Wed, 2008-08-13 at 17:41 +0200, ffileppo wrote:
> What's the difference between using "../gcc/configure" and "../configure" ?

Just depends on where you have your gcc-obj build dir. I have it next to
my gcc source dir. You probably have it inside your gcc source dir.

I am now seeing your failure also. Don't know why I wasn't seeing it
earlier. But I must have tried the wrong thing since I now see why it
cannot have worked.

The latest GNU Classpath import added this patch:

2008-02-08  Roman Kennke  <kennke@aicas.com>

        * gnu/java/awt/peer/gtk/CairoGraphics2D.java,
        * gnu/java/awt/peer/gtk/GdkFontPeer.java,
        * gnu/java/awt/peer/gtk/GdkGraphicsEnvironment.java,
        * gnu/java/awt/peer/gtk/GdkPixbufDecoder.java,
        * gnu/java/awt/peer/gtk/GdkScreenGraphicsDevice.java,
        * gnu/java/awt/peer/gtk/GtkComponentPeer.java,
        * gnu/java/awt/peer/gtk/GtkToolkit.java: Only call
        System.loadLibrary() when configured so.

As Roman explained:

        This changes the System.loadLibrary() calls in the GTK peers, so
        that they are only called when configured so. This is important
        for VMs that can't or don't want to link dynamically, e.g. when
        creating full static linked binaries like Jamaica.

And indeed libgcj has a gnu/classpath/Configuration.java which defines
INIT_LOAD_LIBRARY = false. And so gtkpeer.so is never loaded. Causing
the native jni function call to not resolve giving the
java.awt.AWTError: Cannot load AWT toolkit:
gnu.java.awt.peer.gtk.GtkToolkit [...] Caused by:
java.lang.UnsatisfiedLinkError: initIDs

libgcj does this because it has its own native cni implementation and
doesn't use the classpath jni libraries. Except for... the gtk+ one.

Have to think about the cleanest way to solve this. But reverting this
part of the import (attached) should get you going for now. You'll need
to configure with --enable-java-maintainer-mode (see the libjava/HACKING
file for more explanation).

Cheers,

Mark