I use this command line: gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/local/share/java/ecj.jar to compile ecj.jar into native binary ecj. However, when I try running resulting binary on Hello World Java program it crashes. Original ecj.jar compiles HelloWorld successfully. public class HelloWorld { public static void main(String args[]) { System.out.println("Hello World!"); } }
Works for me: $ gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/share/java/ecj.jar $ ./ecj HelloWorld.java $ java HelloWorld Hello World!
No, it doesn't work for me on FreeBSD-8.0: /usr/local/gcc/4.4.1-java/bin/gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/local/share/java/ecj.jar LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ldd ./ecj ./ecj: libgcc_s.so.1 => /usr/local/gcc/4.4.1-java/lib/libgcc_s.so.1 (0x341ba000) libgcj.so.10 => /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 (0x341c6000) libm.so.5 => /lib/libm.so.5 (0x363d9000) libthr.so.3 => /lib/libthr.so.3 (0x363f3000) librt.so.1 => /usr/lib/librt.so.1 (0x36408000) libc.so.7 => /lib/libc.so.7 (0x3640d000) LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ./ecj HelloWorld.java Segmentation fault: 11 backtrace: #0 0x364041c7 in __error () from /lib/libthr.so.3 #1 0x36403da8 in __error () from /lib/libthr.so.3 #2 0x36606820 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x36606800 in ?? () #6 0x00000000 in ?? () #7 0xbf9fedd4 in ?? () #8 0x363fe1a5 in pthread_rwlock_unlock () from /lib/libthr.so.3 #9 0x36401fae in pthread_cond_signal () from /lib/libthr.so.3 #10 0x34d217e8 in _Jv_CondWait (cv=0x3639778c, mu=0x36397780, millis=0, nanos=0) at ../../../gcc-4.4.1/libjava/posix-threads.cc:212 #11 0x8c34d070 in ?? () #12 0x3639778c in _ZL5mutex () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #13 0x36397780 in E () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000001 in ?? () #18 0x341795a8 in dladdr () from /libexec/ld-elf.so.1
Sounds more like a BSD threads issue, so you need to debug it more.
I confirm this on FreeBSD-8.0 for gcc-4.5.0.20091001. I notified the maintainer of FreeBSD gcc port. But once the fix will be found it should go into gcj itself, not into port.
How to run testsuite for gcj? When I run 'gmake check-gcc' from the build directory it doesn't run gcj tests at all, and gcc/g++ tests summaries are all empty. Not sure what that means.
Would you mind trying again with the latest snapshot/SVN version of GCC (or the current version of lang/gcc45, if you prefer)? There have been some improvements recently to libffi which may make a difference. (It does look like a threading issue, but who knows...) Greg, this may be similar/related to what you have been seeing?
[tc:~] andreast% /usr/local/bin/gcj45 -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main ecj.jar [tc:~] andreast% vi HelloWorld.java public class HelloWorld { public static void main(String args[]) { System.out.println("Hello World!"); } } [tc:~] andreast% setenv LD_LIBRARY_PATH /usr/local/lib/gcc45 [tc:~] andreast% ./ecj HelloWorld.java [tc:~] andreast% gij45 HelloWorld Hello World! [tc:~] andreast% uname -ra FreeBSD tc.andreas.nets 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r201405M: Sat Jan 2 22:32:53 CET 2010 andreast@tc.andreas.nets:/usr/obj/export/devel/fbsd/head/src/sys/TC i386 [tc:~] andreast% gcj45 -v Using built-in specs. Reading specs from /usr/local/lib/gcc45/gcc/i386-portbld-freebsd9.0/4.5.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig COLLECT_GCC=gcj45 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd9.0/4.5.0/lto-wrapper Target: i386-portbld-freebsd9.0 Configured with: ./../gcc-4.5-20091231/configure --disable-nls --libdir=/usr/local/lib/gcc45 --libexecdir=/usr/local/libexec/gcc45 --program-suffix=45 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc45/include/c++/ --with-libiconv-prefix=/usr/local --with-system-zlib --disable-rpath --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc45 --build=i386-portbld-freebsd9.0 Thread model: posix gcc version 4.5.0 20091231 (experimental) (GCC)
Subject: Re: Segmentation fault when ecj.jar is run as a binary compiled by gcj gerald at pfeifer dot com wrote: > ------- Comment #6 from gerald at pfeifer dot com 2010-01-03 13:10 ------- > Would you mind trying again with the latest snapshot/SVN version of GCC > (or the current version of lang/gcc45, if you prefer)? > I tried lang/gcc45 and the problem is gone. Thank you, Yuri
Excellent, thanks for the confirmation that this is fixed for GCC 4.5, Yuri. Andreas, would it make sense to bring your libffi fixes for FreeBSD to GCC 4.4 as well? Would you mind doing this? (Feel free to mark this as resolved, which it is for 4.5 at least.) Thanks!
Hmmm, I need to find out first which of the many patches did solve the issue. After identifying I might do that. Let me start with a gcc44 build on my fbsd i386 box.
A plain gcc44 install does also work here. No patches needed.
Closing per previous comment. Yuri, is it possible a different (older) run-time library was picked up during your original tests?