Compiling "static" applications with SWT/GTK

Steve D. Perkins
Sun Nov 30 06:35:00 GMT 2003

    I've seen, and participated in, a good deal of traffic on this 
mailing list regarding building standalone Win32 gui executables after 
building a static library from SWT.  I'm hoping that someone on this 
list has tried to do the same with SWT for Linux (GTK).  You would think 
that this task, as is most anything regarding GCC-related development, 
would be infinately easier on Linux than in the Win32 world.  However, 
I'm finding the exact opposite to be true.  I've had my Win32 solution 
working for several months, but duplicating the work on a Linux box is 
turning my hair grey!

    The first problem I had to overcome was with header includes.  This 
wasn't even a factor on Win32, since the MinGW environment already 
bundles up everything you need in the win32api.  However, your typical 
Linux installation does not install all the headers you need for 
GTK-based development.  After several hours' worth of trial-and-error, I 
was able to isolate the EIGHT different "XXX-devel" RPM's that I needed 
to extract "/include" headers from... and was able to compile the C 
portion.  Fortunately, native compilation of the Java layer went much 
more smoothly... the modifications you have to make in source are almost 
identical to what's needed for compiling them natively in Win32.

    However, although I've "sucessfully" built static libraries for the 
native and Java layers, I'm encountering problems using them to actually 
compile an application.  Below are the two methods I'm using to attempt 
this, and the problem encounterd with each.  A quick background note:  
SWT for Linux/GTK ships as two separate libraries, one for SWT itself 
and another for the SWT-to-GTK bindings (due to licensing issues between 
SWT and GTK).  At the moment I've bundled up all the source and built 
one native/java library pair.  I've have to change this for licensing 
reasons before I distribute it, but I want to get things working with 
the most simple environment possible before unnecessarily complicating 

(1)  In my first attempt, I used the following command:

gcj-3.3 -fjni 
--main=com.mycompany.MyApplication -o MyApplication MyApplication.jar 

    However, when I then executed "MyApplication", I got the following 

Exception in thread "main" java.lang.UnsatisfiedLinkError: gtk_set_locale
   at _Jv_LookupJNIMethod (/KNOPPIX/usr/lib/
   at org.eclipse.swt.internal.gtk.OS.gtk_set_locale() (Unknown Source)
(Unknown Source)
(Unknown Source)
(Unknown Source)
(Unknown Source)
   at org.eclipse.swt.widgets.Display.Display() (Unknown Source)
   at com.mycompany.MyApplication.main(java.lang.String[]) (Unknown Source)

    For some reason, it wasn't able to find this basic function that's 
part of the GTK library.  As an experiment, I commented out the 
"Library.loadLibrary("swt-pi")" call in 
"org.eclipse.swt.internal.gtk.OS" (this call was worthless anyway since 
you basically comment-out all the functionality of that method to 
support static linking).  In it's place, I inserted the call 
"System.loadLibrary("gtk")" in ensure that applications would try to 
look for the GTK shared library.  I rebuilt everything, and got the same 
result.  I confirmed that I AM using the "-fjni" flag when building the 
library, but for some reason the call to native method isn't working.

(2)  After beating my head against that problem for awhile, I decided to 
try removing the dependency on the GCJ shared library... since I do not 
want to make installing GCJ a requirement for using applications I 
build.  I changed the compile command to look like this:

gcj-3.3 -fjni 
--main=com.mycompany.MyApplication -o MyApplication MyApplication.jar 

    However, upon executing "MyApplication", I now get this output:

libgcj failure: Duplicate class registration: java.lang.Class

    Do either of these scenerios make sense to anyone, or is there 
anyone who has accomplished what I'm attempting and can point me in 
another direction?  My brain has simply turned to mush thinking about 
it... I'm going to put the problem aside for awhile, concentrate on the 
Win32 side, and look at the Linux environment later with a fresh mind.


More information about the Java mailing list