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

Tom Tromey tromey@redhat.com
Wed Nov 27 23:56:00 GMT 2002

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Tom> I believe this lets us get names for symbols in a stack trace.

Adam> Really?  I thought that this was done with debugging symbols.  How
Adam> would this help us get symbol names for functions which aren't
Adam> exported?

I think you're right.

It looks like we dlopen ourselves in Runtime.init:

  lt_dlhandle self = lt_dlopen (NULL);
  if (self != NULL)
    add_library (self);

As I recall this lets us find JNI symbols in the executable.  I think
this lets people prelink the JNI library into their program and have
it work (though I don't recall ever testing this).

Tom> We could compile libgcj.a differently.

Adam> Interesting, but aren't all the .o's compiled once, and then simply
Adam> linked differently for libgcj.a versys libgcj.so?

Nope, by default libtool compiles every file twice.

That may not be true on all platforms, though I'm not positive.  On
AIX shared and static libraries are the same, I think.  But we don't
really support AIX yet, either (only since nobody has done the port),
and anyway AIX won't have this glibc-specific problem you're seeing.

Really I'd prefer not to do this.  Compiling static and dynamic
libraries differently just makes more opportunities for obscure bugs.


More information about the Java mailing list