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

[Adam Megacz <gcj at lists dot megacz dot com>]

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?


> 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?


> That will make stack traces not work correctly when statically
> linked.

Yeah, I should probably get around to porting my
reflection-metadata-stack-trace stuff to the new 1.4 exception
mechanism.

  - a