Re: seg fault on startup

[Andrew Haley <aph at redhat dot com>]

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.