This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Compiling "static" applications with SWT/GTK
- From: Erik Poupaert <erik dot poupaert at skynet dot be>
- To: mailinglists at steveperkins dot net
- Cc: java at gcc dot gnu dot org
- Date: Sun, 30 Nov 2003 19:15:03 +0000
- Subject: RE: Compiling "static" applications with SWT/GTK
- Organization: Erik Poupaert
Hi
You write:
"""
gcj-3.3 -fjni
-fCLASSPATH=/mnt/hda1/eclipse/workspace/nativeCompiler/SWT-LinuxGTK/swt.jar
--main=com.mycompany.MyApplication -o MyApplication MyApplication.jar
/mnt/hda1/eclipse/workspace/nativeCompiler/SWT-LinuxGTK/libswtjava.a
/mnt/hda1/eclipse/workspace/nativeCompiler/SWT-LinuxGTK/libswtnative.a
However, when I then executed "MyApplication", I got the following
output:
Exception in thread "main" java.lang.UnsatisfiedLinkError: gtk_set_locale
at _Jv_LookupJNIMethod (/KNOPPIX/usr/lib/libgcj.so.4.0.0)
at org.eclipse.swt.internal.gtk.OS.gtk_set_locale() (Unknown Source)
...
"""
The problem is in:
/mnt/hda1/eclipse/workspace/nativeCompiler/SWT-LinuxGTK/libswtnative.a
You need to wrap the native part in a whole archive option, in order to force its
inclusion:
-Wl,--whole-archive
/mnt/hda1/eclipse/workspace/nativeCompiler/SWT-LinuxGTK/libswtnative.a
-Wl,--no-whole-archive
Without the whole-archive option, you the linker will not include any of
libswtnative.a functions, because they are only referenced dynamically through
_Jv_LookupJNIMethod(). At compile time, the linker can't see they are actually being
used, and he will drop them from the executable you are creating. By the way, this
works exactly the same as on win32.
>>> In it's place, I inserted the call
>>> "System.loadLibrary("gtk")" in ensure that applications would try to
>>> look for the GTK shared library.
Not enough. The libraries required are (for gtk/x11):
-lgtk-x11-2.0 \
-lgdk-x11-2.0 \
-latk-1.0 \
-lgdk_pixbuf-2.0 \
-lm \
-lpangoxft-1.0 \
-lpangox-1.0 \
-lpango-1.0 \
-lgobject-2.0 \
-lgmodule-2.0 \
-ldl \
-lglib-2.0 \
-lgthread-2.0 \
-lpthread
Add these link options to your linking instruction.
> I decided to try removing the dependency on the GCJ shared library...
Won't work. When you link with gcj, it will issue the ld linker instructions which
will link libgcj.so anyway. So, linking libgcj.a *and* libgcj.so twice will cause the
error you encountered:
libgcj failure: Duplicate class registration: java.lang.Class
Aborted
You can't just simply link statically on linux with libgcj.a. It requires re-building
gcj with the configuration option. It is not well-supported though.
For non-GUI applications, I've noticed that linking statically works fine with:
$ gcj -static ...
With SWT applications, it fails on linking the GTK libraries statically. They must be
built statically (configuration option for the GTK libraries), but I haven't tried
that one by myself.