Re: GCJ application runs not too bad with shared libs, but crasheswith static libs - seems to be in _Jv_MonitorEnter

[Andrew Haley <aph at redhat dot com>]

Adam Megacz top-posts:
 > 
 > Correct me if I'm wrong, but if the binary is statically linked how
 > could the version of libgcj.so on the system have any influence at
 > all?

It won't, but if a binary works on one system but not another there
are only three possibilities:

The environment
The libraries
The kernel

So, the only way forward is to debug this thing.  There isn't any
doubt in my mind that _something_ has incorrect DWARF2 unwinder data.
A debug session whould determine where that data has come from.

Andrew.

 > Mark Wielaard <mark@klomp.org> writes:
 > > 
 > > On Sat, 2002-11-23 at 12:49, Andrew Haley wrote:
 > > > Mark Wielaard writes:
 > > >  > On Fri, 2002-11-22 at 20:50, Adam Megacz wrote:
 > > >  > > It's statically linked, but it crashed for me with newer glibc's.
 > > >  > > This should help determine if it's your compiler or your system.
 > > >  > 
 > > >  > Thanks. This might also explain an error I am trying to track down this
 > > >  > whole day :( On my main development machine I recently upgraded to glibc
 > > >  > 2.3.1. When I got this email I checked on another machine that is still
 > > >  > running glibc 2.2.5 and all seems to work OK there...
 > > >  > 
 > > >  > I am also seeing strange things when using gij to interpret byte code on
 > > >  > the glibc 2.3.1 system:
 > > > 
 > > > This looks to me like there may be some sort of version mismatch with
 > > > libraries.
 > > 
 > > I setup a small partition with Debian testing (glibc 2.2.5 based) which
 > > works correctly (my main partition has Debian unstable, glibc 2.3.1
 > > based which shows the strange behaviour). I can hack again on libgcj now
 > > which makes me happy. I will try to investigate the breakage later. For
 > > now I just want to warn people not to upgrade to Debian unstable (and
 > > maybe other distributions that use glibc 2.3.1).