linux audio software using gcj&swt!

Andrew Haley aph@redhat.com
Thu Oct 23 11:33:00 GMT 2003


Norbert Frese writes:
 > 
 > > Static linking with Java is tricky. Certain resources may be missing 
 > > because they are only loaded dynamically (ie Class.forName), and the 
 > > linker can't see that to include them. One workaround is to add static 
 > > links to the missing classes in your code ie:
 > > 
 > > static class foo = gnu.java.localeCalendar.class;
 > > 
 > 
 > i have added the lines 
 > 
 > static Class foo = gnu.java.locale.Calendar.class;
 > static Class foo2 = gnu.java.locale.LocaleInformation.class;
 > 
 > and the exceptions are gone. but there seems to be a problem with swt
 > now. the appliction starts up - then hangs (cpu 99%) for a while and
 > drops core (segmentation fault). (i think it hangs inside "new
 > Display()")

I've seen that.  I think it happens when trying to load a shared
library from a static executable.  Run your app in gdb; you might see
something like

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x40caf3a6 in ?? ()
#2  0x40cb4761 in ?? ()
#3  0x40ca9b99 in ?? ()
#4  0x081908da in _dl_init ()
#5  0x08179264 in dl_open_worker ()
#6  0x081785d3 in _dl_catch_error ()
#7  0x08178e3f in _dl_open ()
#8  0x08153208 in dlopen_doit ()
#9  0x081785d3 in _dl_catch_error ()
#10 0x08153490 in _dlerror_run ()
#11 0x081531d5 in dlopen ()
#12 0x0811ab03 in GC_dlopen (path=0x0, mode=0) at /local/aph/gcc/gcc/boehm-gc/gc_dlopen.c:81
#13 0x080bdbbb in sys_dl_open (loader_data=0x0, filename=0x0)
    at /local/aph/gcc/gcc/libjava/libltdl/ltdl.c:296
#14 0x080bb716 in tryall_dlopen (handle=0xbfffe1b8, filename=0x83730e0 "lib-foo.so")
    at /local/aph/gcc/gcc/libjava/libltdl/ltdl.c:937
#15 0x080bc768 in lt_dlopen (filename=0x83730e0 "lib-foo.so")
    at /local/aph/gcc/gcc/libjava/libltdl/ltdl.c:1511
#16 0x080bda60 in lt_dlopenext (filename=0xbfffe210 "lib-foo")
    at /local/aph/gcc/gcc/libjava/libltdl/ltdl.c:1603
#17 0x08072160 in java::lang::Runtime::loadLibraryInternal(java::lang::String*) (this=0x0, 
    lib=0x81c1aac) at /local/aph/gcc/gcc/libjava/java/lang/natRuntime.cc:272

Maybe we can't load a library from a statically linked exectuable
without crashing.  Let's try something simple:

#include <stddef.h>
#include <dlfcn.h>
int main ()
{
  dlopen ("lib-foo.so", RTLD_NOW);
  char *s = dlerror();
  puts (s ? s : "");
  return 0;
}

 $ gcc z.c -ldl -static -g
 $ ./a.out 
Segmentation fault

 $ gdb ./a.out 
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) r
Starting program: /cuddles/aph/home/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x409163a6 in ?? ()
#2  0x4091b761 in ?? ()
#3  0x40910b99 in ?? ()
#4  0x0807b6ba in _dl_init ()
#5  0x0805b920 in dl_open_worker ()
#6  0x0805ac8f in _dl_catch_error ()
#7  0x0805b4fb in _dl_open ()
#8  0x0804829c in dlopen_doit ()
#9  0x0805ac8f in _dl_catch_error ()
#10 0x080484a4 in _dlerror_run ()
#11 0x08048269 in dlopen ()
#12 0x08048214 in main () at z.c:5
#13 0x08048813 in __libc_start_main ()

Bingo.  Same error.  

If I try this same experiment with libc.so.6, instead of lib-foo.so
there is no problem.  I think it's because the lib-foo.so I created
depends on libgcc_s.so.1 and libgcj.so.4, and there are static
versions of thses already linked to the executable.

So, we shouldn't attempt to load a shared library from a static gcj
executable.  I don't think there's any way to make it work.

 > i guess building a static binary (which includes libgcj) on linux is
 > really a tricky task. i've seen that other people gave up on this (read
 > the posts on this mailing list). :-(

Well, the question here is why libgcj is trying to load a library.
There must be a reason, probably because some dependency in Display is
trying to resolve something in a shared library.

Time to debug.

Andrew.



More information about the Java mailing list