seg fault on startup

Mon Mar 19 18:57:00 GMT 2007

Ben Tatham writes:
 > (gdb) info share
 > >From To Syms Read Shared Object Library
 > No /usr/lib/libgcc_s.so.1
 > 0x0f1e5000 0x0f9158a8 Yes /usr/lib/libgcj.so.7
 > 0x0e7324f0 0x0e749f8c Yes /lib/libm.so.6
 > 0x0e6c22b0 0x0e6ccc4c Yes /lib/libpthread.so.0
 > 0x0e69bea0 0x0e69cd80 Yes /lib/libdl.so.2
 > 0x0e551a40 0x0e6543e8 Yes /lib/libc.so.6
 > No /lib/ld.so.1
 > 
 > 
 > And the links on my target platform...confirming I am running the 
 > correct shared libs. 
You need to go into the debugger to find out what is at
> > #5696 0x7ffff998 in ?? ()

and how you got there. It doesn't seem like shared libraries.
 > However, I was making a mistake earlier...I had foo.debug and
 > Foo.debug, but my silly windows intermediary screwed up the ftps to
 > my target, so I wasn't actually running the debug version of the
 > statically linked version. Anyway, the point is that the
 > statically linked version of Foo works in both the stripped and
 > non-stripped cases -- which would seem to indicate that perhaps it
 > is not the correct version of libgcj...but as far as I can tell, I
 > do have the correct versions.
OK.
 > Other versions of interest, libc.so: 2.3.1. Our GCJ is technically 
 > compiled for libc 2.3.3, but we have been running gcc-4.0.1-libc-2.3.3 
 > for some time without a problem. We cannot seem to compile gcc/gcj 
 > 4.1.2-libc-2.3.1 though. 
 > And besides, the statically linked version still depends on libc,
 > ld, lm, etc. and works fine, so I don't think that is the problem.
That's binutils, not libc.
Andrew.