Re: Compiling "static" applications with SWT/GTK

["Steve D. Perkins" <mailinglists at steveperkins dot net>]

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