seen on redhat/gcc-4_1-branch, should be seen on upcoming classpath-0.92 merge as well. building a shared library avoids the direct dependency on libgcj.so.7 (only libgcj_gc.so.1 is referenced as NEEDED). i.e. gcj \ -O2 -g -Wl,-Bsymbolic -shared -fPIC -fjni -findirect-dispatch \ -o build/dist/ecj.jar.so build/dist/ecj.jar ecj.jar.so doesn't depend on libgcj.so.7, while building an executable, i.e. gcj \ -O2 -g -Wl,-Bsymbolic -fPIC -fjni -findirect-dispatch \ --main=org.eclipse.jdt.internal.compiler.batch.Main \ -o build/dist/ecj-bootstrap-gcj build/dist/ecj.jar still has the dependency on libgcj.so.7. using the latter compiler is still faster than starting the interpreter and using the precompiled jar file. libjava/libgcj.spec does only rename the spec for linking shared libs, not for linking executables. Matthias
For a simple example it does not do this: opsy. gcj -O2 -fPIC -fjni -findirect-dispatch -o H --main=HelloWorld HelloWorld.class opsy. eu-readelf -d H|fgrep lib NEEDED Shared library: [libgcc_s.so.1] NEEDED Shared library: [libgcj_bc.so.1] NEEDED Shared library: [libm.so.6] NEEDED Shared library: [libpthread.so.0] NEEDED Shared library: [librt.so.1] NEEDED Shared library: [libdl.so.2] NEEDED Shared library: [libc.so.6] I wonder if something else is going on here... maybe some optimization is generating a symbol that necessitates pulling in libgcj itself? (I'm thinking of the builtins ... though I thought Andrew fixed these. So, maybe that is wrong.)
ecj.jar is from eclipse-3.2, copied the file to http://people.ubuntu.com/~doko/ecj.jar gcj-4.2 -v \ -O2 -g -Wl,-Bsymbolic -shared -fPIC -fjni -findirect-dispatch \ -o /tmp/ecj.jar.so /usr/share/java/ecj.jar Using built-in specs. Reading specs from /usr/lib/gcc/i486-linux-gnu/4.2.0/libgcj.spec [...] gcc version 4.2.0 20060817 (experimental) (Ubuntu 4.2-20060817-0ubuntu1) gcj-4.2 -v \ -O2 -g -Wl,-Bsymbolic -fPIC -fjni -findirect-dispatch \ --main=org.eclipse.jdt.internal.compiler.batch.Main \ -o /tmp/ecj /usr/share/java/ecj.jar Using built-in specs. Reading specs from /usr/lib/gcc/i486-linux-gnu/4.2.0/libgcj.spec [...] objdump -x /tmp/ecj.jar.so | grep NEEDED NEEDED libgcc_s.so.1 NEEDED libgcj_bc.so.1 NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED librt.so.1 NEEDED libz.so.1 NEEDED libdl.so.2 NEEDED libc.so.6 objdump -x /tmp/ecj | grep NEEDED NEEDED libgcc_s.so.1 NEEDED libgcj_bc.so.1 NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED librt.so.1 NEEDED libz.so.1 NEEDED libdl.so.2 NEEDED libc.so.6 NEEDED libgcj.so.8
Created attachment 12091 [details] example more simple example from the gettext source, compiled with gcj -C gnu/gettext/GetURL.java gcj -v -fjni -findirect-dispatch gnu/gettext/GetURL.class --main=gnu.gettext.GetURL -o gnu.gettext.GetURL
Bryce pointed out that we need to deal with the primitive class objects somehow. Otherwise code like 'new int[5]' will pull in libgcj.so. I'll send a patch to the java-patches list. Could you try it on your test cases? I tried in on my copy of ecj.jar and verified that it works.
What does "ldd" on the dummy (unversioned) libgcj_bc.so say? This library should not be linked against libgcj.so, maybe it is being linked incorrectly.
There seems to be a mismatch in the installation of the unversioned libgcj_bc.so in the fc rpm and the trunk. On the trunk, this library is created using $(libgcj_bc_dummy_LINK) -xc /dev/null -Wl,-soname,libgcj_bc.so.1 \ -o $(DESTDIR)$(toolexeclibdir)/libgcj_bc.so.1.0.0 -lgcj where libgcj is the real libgcj.so, while in the spec file, a dummy libgcj.so is created first. mkdir libgcj_bc gcc/xgcc -B gcc/ $OPT_FLAGS $LIBGCJ_BC_CFLAGS -shared -fpic -xc /dev/null \ -o libgcj_bc/libgcj.so -Wl,-soname,libgcj.so.7rh -nostdlib gcc/xgcc -B gcc/ $OPT_FLAGS $LIBGCJ_BC_CFLAGS -shared -fpic ../libjava/libgcj_bc.c \ -o libgcj_bc/libgcj_bc.so -Wl,-soname,libgcj_bc.so.1 libgcj_bc/libgcj.so -shared-libgcc Although that code seems to be called for the biarch case only. The ldd on libgcj.so shows the dependency on the real libgcj on the trunk, no dependency with the code from the spec file. Matthias
There's some kind of skew here... I took the code on the trunk from the RH 4.1 branch, not from the FC RPM.
Subject: Bug 28698 Author: tromey Date: Thu Aug 31 17:23:57 2006 New Revision: 116603 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116603 Log: PR libgcj/28698: * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro. Declare primitive classes. Modified: trunk/libjava/ChangeLog trunk/libjava/libgcj_bc.c
Subject: Bug 28698 Author: tromey Date: Thu Aug 31 22:00:06 2006 New Revision: 116607 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116607 Log: PR libgcj/28698: * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro. Declare primitive classes. Modified: branches/redhat/gcc-4_1-branch/libjava/ChangeLog branches/redhat/gcc-4_1-branch/libjava/libgcj_bc.c
Subject: Bug 28698 Author: tromey Date: Fri Sep 1 16:16:15 2006 New Revision: 116631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116631 Log: PR libgcj/28698: * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro. Declare primitive classes. boehm-gc PR libgcj/13212: * configure.ac: Check for pthread_getattr_np(). Remove GC_PTHREAD_SYM_VERSION detection. * include/gc.h (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New declarations. * pthread_support.c (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New functions. (GC_delete_thread): Don't try to free the first_thread. * misc.c (GC_init_inner): Use GC_get_thread_stack_base() if possible. (pthread_create_, constr): Removed. (pthread_create): Don't rename. * include/gc_ext_config.h.in: Rebuilt. * include/gc_pthread_redirects.h (pthread_create): Define unconditionally. * include/gc_config.h.in: Rebuilt. * configure: Rebuilt. libjava * java/lang/natThread.cc (_Jv_AttachCurrentThread): Attach thread to GC. (_Jv_DetachCurrentThread): Detach thread from GC. * include/boehm-gc.h (_Jv_GCAttachThread, _Jv_GCDetachThread): Declare. * boehm.cc (_Jv_GCAttachThread): New function. (_Jv_GCDetachThread): Likewise. gcc/java/ChangeLog * jvspec.c (lang_specific_driver): Add -s-bc-abi when needed. libjava/ChangeLog * configure, Makefile.in: Rebuilt. * Makefile.am (toolexeclib_LTLIBRARIES): Add libgcj_bc.la. (libgcj_bc_la_SOURCES): New variable. (libgcj_bc_la_LDFLAGS): Likewise. (libgcj_bc_la_LIBADD): Likewise. (libgcj_bc_la_DEPENDENCIES): Likewise. (libgcj_bc_la_LINK): Likewise. (libgcj_bc_dummy_LINK): Likewise. (libgcj_bc.la): New target. (install-exec-hook): Likewise. * libgcj.spec.in (*lib): Use LIBGCJ_SPEC. * libgcj_bc.c: New file. * configure.ac (LIBGCJ_SPEC): New subst. * configure.host (use_libgcj_bc): New variable. Added: branches/gcj-eclipse/libjava/libgcj_bc.c - copied, changed from r116204, trunk/libjava/libgcj_bc.c Modified: branches/gcj-eclipse/boehm-gc/ChangeLog branches/gcj-eclipse/boehm-gc/configure branches/gcj-eclipse/boehm-gc/configure.ac branches/gcj-eclipse/boehm-gc/dyn_load.c branches/gcj-eclipse/boehm-gc/include/gc.h branches/gcj-eclipse/boehm-gc/include/gc_config.h.in branches/gcj-eclipse/boehm-gc/include/gc_ext_config.h.in branches/gcj-eclipse/boehm-gc/include/gc_pthread_redirects.h branches/gcj-eclipse/boehm-gc/include/private/pthread_support.h branches/gcj-eclipse/boehm-gc/misc.c branches/gcj-eclipse/boehm-gc/os_dep.c branches/gcj-eclipse/boehm-gc/pthread_stop_world.c branches/gcj-eclipse/boehm-gc/pthread_support.c branches/gcj-eclipse/gcc/java/ChangeLog branches/gcj-eclipse/gcc/java/jvspec.c branches/gcj-eclipse/libjava/ChangeLog branches/gcj-eclipse/libjava/Makefile.am branches/gcj-eclipse/libjava/Makefile.in branches/gcj-eclipse/libjava/boehm.cc branches/gcj-eclipse/libjava/configure branches/gcj-eclipse/libjava/configure.ac branches/gcj-eclipse/libjava/configure.host branches/gcj-eclipse/libjava/gcj/Makefile.in branches/gcj-eclipse/libjava/include/Makefile.in branches/gcj-eclipse/libjava/include/boehm-gc.h branches/gcj-eclipse/libjava/java/lang/natThread.cc branches/gcj-eclipse/libjava/libgcj.spec.in branches/gcj-eclipse/libjava/testsuite/Makefile.in
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.