Re: gcj 4.4 and AWT toolkit

[Andrew Haley <aph@redhat.com>]

ffileppo wrote:
>> 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).

Thanks Mark.  We definitely need this fix in mainline gcj.

Andrew.