Compiling "static" applications with SWT/GTK

[Steve D. Perkins]

>
>
>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!  ;)