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 writes:
 > 
 > Tom Tromey <tromey@redhat.com> writes:
 > > Adam> Well, for now I just disabled the code that sets user.home/user.dir.
 > 
 > > I don't think we can do that in cvs though.
 > 
 > Agreed.  Although if we can detect static linkage at runtime, that
 > might be a solution.  Perhaps even a hack involving fork()ing
 > /bin/who.
 > 
 > 
 > > Adam> The other problem is that natRuntime::init() tries to dlopen()
 > > Adam> itself... why does it do this?
 > 
 > > I believe this lets us get names for symbols in a stack trace.
 > 
 > Really?  I thought that this was done with debugging symbols.  How
 > would this help us get symbol names for functions which aren't
 > exported?

It wouldn't.  We could also use degugging symbols for DSOs, or
alternatively give up forking external processes altogether and use
reflection data instead.  Trouble is, reflection data woudn't get you
the names of non-Java functions or line numbers.  I'm still tempted to
do this, though.

 > > Adam> Is there any way to detect at runtime if this binary is a static
 > > Adam> binary (and then not try to dlopen)?
 > 
 > > We could compile libgcj.a differently.
 > 
 > Interesting, but aren't all the .o's compiled once, and then simply
 > linked differently for libgcj.a versys libgcj.so?

Sadly not!

Andrew.