This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
SWT in a DLL [long]
- From: Cristiano Paris <frodo at theshire dot org>
- To: java at gcc dot gnu dot org
- Date: Wed, 07 Dec 2005 13:26:58 +0100
- Subject: SWT in a DLL [long]
Hi everyone,
I've posted this in the MingW mailing list but I haven't received much
feedback: maybe the topic in more appropriate for this mailing list than
the MingW one. I'm sorry if this mail is a duplicate for some of you.
I'm new to the mingw/gcj and I'm experimenting hard. I've successfully
built the GNU Toolchain for the mingw32 target both for Linux and Windows.
Details of the toolchain:
- gcc 4.0.2
- binutils 2.16.1
- w32api 3.5
- mingw-runtime 3.9
I could compile simple SWT/JFace applications using gcj and the
SWT/JFace libraries compiled in statically.
Now I'm experimenting with DLLs. I've compiled the following code:
mydll.java:
public class mydll
{
public int doubling(int i)
{
return i*2;
}
}
which implements a simple DLL, and:
main.java:
public class main
{
public static void main(String[] args)
{
mydll dll = new mydll();
System.out.println("Result = " + dll.doubling(5));
}
}
which calls the class's method. I've compiled the DLLs and the EXE
following these steps:
gcj -c -findirect-dispatch -fjni mydll.java
gcj -shared -o mydll.dll -Wl,--out-implib,mydll.dll.a \
-Wl,--export-all-symbols -Wl,-S -Wl,-s mydll.o
gcj -c --classpath=. main.java
gcj --main=main -o test.exe main.o -L. -lmydll
and it works as expected though I see these (I think harmless) messages:
Info: resolving __ZN5mydll6class$E by linking to
__imp___ZN5mydll6class$E (auto-import)
I've noticed that leaving out the indirect-dispatch switch when
compiling the mydll.java source makes test.exe complain at run-time.
Well, now for the great move.
I tried to compile the swt.jar that comes with SWT 3.1.1 the same way:
gcj -c -findirect-dispatch -fjni swt.jar
gcj -shared -o swtcom.dll -Wl,--out-implib,swtcom.dll.a \
-Wl,--export-all-symbols -Wl,-S -Wl,-s swt.o
gcj -c --classpath=swt.jar SWTHello.java
gcj --main=SWTHello -o SWTHello.exe SWTHello.o -L. -lswtcom
As before gcj issues the following messages:
Info: resolving __ZN3org7eclipse3swt7widgets7Display6class$E by linking
to __imp___ZN3org7eclipse3swt7widgets7Display6class$E (auto-import)
Info: resolving __ZN3org7eclipse3swt7widgets5Shell6class$E by linking to
__imp___ZN3org7eclipse3swt7widgets5Shell6class$E (auto-import)
Info: resolving __ZN3org7eclipse3swt6layout9RowLayout6class$E by linking
to __imp___ZN3org7eclipse3swt6layout9RowLayout6class$E (auto-import)
Info: resolving __ZN3org7eclipse3swt7widgets5Label6class$E by linking to
__imp___ZN3org7eclipse3swt7widgets5Label6class$E (auto-import)
but now SWTHello.exe doesn't work:
Exception in thread "main" java.lang.NoClassDefFoundError: while
resolving class: org.eclipse.swt.widgets.Display
at java.lang.VMClassLoader.transformException(java.lang.Class,
java.lang.Throwable)
(C:\home\paris\mingw\gcc-4.0.2\libjava\java\lang\VMClassLoader.java:138)
at java.lang.VMClassLoader.resolveClass(java.lang.Class)
...
Notice that using static linkage everything works fine.
Am I trying to do something unachievable with current gcc/gcj and SWT?
Thank you for any reply,
Cristiano