Re: Patch: java class registration via .jcr section, take 3

[Jeff Sturm <jsturm at one-point dot com>]

On 10 Aug 2001, Tom Tromey wrote:

> >>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:
> 
> Jakub> Not that much, since I think whenever you're linking in some
> Jakub> Java code you really want to use gcj for the final link, so
> Jakub> that it will bring needed libraries etc. (that will bring in
> Jakub> -lstdc++ and -lc too).
> 
> I don't really understand all the issues here.
> 
> At some point we'll support the JNI invocation API.  When we do this
> it will be possible to write a simple C program which links against
> the libgcj runtime and starts Java via some JNI calls.
> 
> Won't we need the magic stuff in crt0 (or whereever) for this to work?

Typically, that JNI program will dynmically load libgcj and other Java
libs.  Those DSOs will have the appropriate startup code for class
registration.

It should also be possible to statically link a JNI program, in which case
the simplest thing is to do the final link with gcj.

I don't think this is a very important issue.

> Jakub> BTW: What's the reason why libgcj does not have DT_NEEDED
> Jakub> libgcjgc.so.1 when it really needs it (and likewise for libzgcj
> Jakub> (resp libz))?
> 
> I don't even understand the question.  That is probably the
> reason. :-)

He means that libgcj.so isn't explicitly linked to libgcjgc and libzgcj.
That's probably because most of the libgcj work so far has been on ELF
targets, which let you get away with undefined symbols.  (IMHO
-no-undefined ought to be the default when linking with libtool to catch
these sorts of potential problems.)

I'm not too concerned, since there has been some dicussion that
libgcjgc/libzgcj may go away or become convenience libraries soon (I
really need to find some time and unload my backlog of patches again).

Jeff