gcj 4.4 and AWT toolkit

Thu Aug 14 13:24:00 GMT 2008

>> 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).
>
Hi Mark,
thanks a lot for your help.
I'll try this change and I'll let you know.
Francesco