Re: gcj 4.4 and AWT toolkit

>
> 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  <[email protected]>
>
>         * 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).
>

Hi Mark,

thanks a lot for your help.
I'll try this change and I'll let you know.

Francesco