Re: OpenOffice and gcj at runtime

[Caolan McNamara <caolanm at redhat dot com>]

On Tue, 2004-12-07 at 09:35 -0700, Tom Tromey wrote:
> >>>>> "Caolan" == Caolan McNamara <caolanm@redhat.com> writes:
> 
> Caolan> with (FC3) gcj/g++ 3.4.2 this example fails
> Caolan> with (rawhide) gcj/g++ 3.4.3 this example fails
> Caolan> with gcj/g++ from head (20041126) this example passes.
> 
> With the FC2 gcj, this does something at least:
> 
> opsy. type gcj
> gcj is /usr/bin/gcj
> opsy. rpm -q gcc-java
> gcc-java-3.3.3-7
> opsy. sh runme.gcj.sh
> registerInterfaceA is 959e668
> registerInterfaceB is 95b47e0
> A: registerInterface
> A: registerInterface

> Some versions of gcj did have a bug when calling an interface method
> via JNI.  Is that what you're running into?  Do you get a
> NullPointerException or something?
> 

That's what I want all right, and forcing the example to link directly
against libgcj.so.4 gives me the same results as you had, so libgcj.so.5
and .6 are the culprits, while libgcj.so.4 is behaving itself.

> We can fix this on some branch or another, especially since it seemed
> to work in 3.3 (regressions get special dispensation, usually).
> This example doesn't work in the BEA JDK :-)

Excellent that its a regression :-)

> Caolan> Mixing gcj from head and g++ 3.4.2 and the example fails, which is
> Caolan> more-or-less what I was doing with OOo (started with 3.4.2 and moved to
> Caolan> the head gcj because of the URL snafu) :-) I deserved that I guess, can
> Caolan> hardly complain about doing something odd like that.
> 
> Were there changes to libgcc?  If not, I would actually expect this to
> work ok.  It seems to me that you wouldn't hit C++ ABI problems as the
> JNI stuff is all inlined...
> 
> What goes wrong?
> 
> It would be nice to get this approach working, because most of the
> other java stuff we're looking at (for, say, FC4) will most likely be
> compiled with gcj4.

Yeah, I've whipped up a better dlopening example which is a fairer
reflection of what OOo wants to do
http://people.redhat.com/caolanm/gcj.problems/runtime2.tar.gz 
and with it I can see that libgcj.so.4 is ok, while libgcj.so.5
hangs/crashes on the second CallObjectMethodA, and libgcj.so.6 silently
fails on the second CallObjectMethodA. Forcing the module which causes
grief in OOo to use libgcj.so.4 at runtime works, so its apparently down
to the same type of problem which had slightly different results between
libgcj.so.5/libgcj.so.6.

C.