This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Natively compiled SWT segfaults under Windows
- From: Olivier Parisy <ml dot olivier dot parisy at free dot fr>
- To: java at gcc dot gnu dot org
- Date: Mon, 14 Aug 2006 17:14:07 +0200
- Subject: Natively compiled SWT segfaults under Windows
Hi,
I've successfully built a gcj toolchain under Windows/MinGW using
rmathew's excellent instructions at :
http://www.rmathew.com/articles/gcj/bldgcj.html
My setup :
binutils-2.16.1.tar.bz2
gcc-4.2-20060805.tar.bz2
mingw-runtime-3.10.tar.gz
w32api-3.7.tar.gz
Compiling and running an helloworld does work.
I was also able to compile and link basic SWT code, but it dies silently
at run time.
Executing it under GDB, I got:
Program received signal SIGSEGV, Segmentation fault.
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*) (
trace_fn=0xbcd700 <_Jv_StackTrace::UnwindTraceFn(_Unwind_Context*,
void*)>, state=0x23f2cc) at ./sysdep/backtrace.h:
86
86 ./sysdep/backtrace.h: No such file or directory.
in ./sysdep/backtrace.h
I am kind of stuck. It seems like this backtrace.h file has been
discussed recently:
http://gcc.gnu.org/ml/java-patches/2006-q3/msg00101.html
but this doesn't look like the same issue.
Here is a simple test case to reproduce this bug (this runs fine using
ecj/eclipse). The code dies during the Display instantiation:
import org.eclipse.swt.widgets.Display;
public class TestSWT {
public static void main(String[] args) {
try {
System.out.println("Setting up display...");
Display display = new Display();
System.out.println("Display set up");
} catch (Throwable t) {
t.printStackTrace(System.out);
}
System.out.println("Done");
}
}
And I compile it this way (which is painfully slow BTW):
gcj -g
--classpath=src;build;lib/org.eclipse.swt.win32.win32.x86_3.2.0.v3232g.jar
-c src\TestSWT.java -o build\TestSWT.o
gcj -fjni lib/org.eclipse.swt.win32.win32.x86_3.2.0.v3232g.jar -g -o
build\app.exe --main=TestSWT build\TestSWT.o
Note that the SWT dll is in my PATH; if not, the application dies with
the usual UnsatisfiedLinkError.
Any hint? Is this problem already solved by patches I may apply?
Best regards,
Olivier Parisy.