Compiling "static" applications with SWT/GTK

Mon Dec 1 02:43:00 GMT 2003

>>>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.
>>
Hi Erik -
 I remember us having an offline discussion on this a few months ago
as I was getting the Win32 version working. I'm not sure what "magic"
I'm using, but I've never used any "-Wl" options of any kind on Win32.
When I compile a native SWT app on Windows with GCJ, I'm using these
commands:
"C:/eclipse/workspace/nativeCompiler/GCJ-Win32/bin/dlltool" --dllname
"MyApplication.exe" --output-exp "C:\\MyApplication.exp" --def
"C:/eclipse/workspace/nativeCompiler/SWT-Win32/swtnative.def"
"C:/eclipse/workspace/nativeCompiler/GCJ-Win32/bin/gcj" -mwindows -fjni
-fCLASSPATH="C:/eclipse/workspace/nativeCompiler/SWT-Win32/swt.jar"
--main=com.mycompany.MyApplication -o "C:\\MyApplication.exe"
"C:\\MyApplication.exp"
"C:/eclipse/runtime-workspace/MyProject/MyApplication.jar"
"C:/eclipse/workspace/nativeCompiler/SWT-Win32/swtnative.a" -lole32
-lcomctl32 -luser32 -lgdi32 -lcomdlg32 -lkernel32 -lshell32 -ladvapi32
-limm32 -lwinspool -loleaut32
"C:/eclipse/workspace/nativeCompiler/GCJ-Win32/bin/strip"
"C:\\MyApplication.exe"
>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've added these libraries to my link options, and still have more
failed dependencies then I wish to list here. I'll keep plugging away
at it, but there's still something that I'm missing out on.
>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.
> This is just crazy. Forcing a dependency on a GCJ shared library
eliminates much of the advantage of native compilation in the first
place (deployment without a JRE). I received an offline email earlier
today from Norbert Frese, describing how he got around this problem. I
really appreciated that, but didn't have much luck when trying that
advice... I'll dive back into it once I get things working "normally".
 Anyone who claims that Linux is "more developer-friendly" than Win32
is smoking crack! ;)