John M. Gabriele writes:
>
> >
> > Yes. Unless you are using indirect dispatch, the run-time dynamic
> > linker (i.e. that used by the OS for loading C programs) of your OS
> > will try to link against a shared object file and will fail if it
> > isn't there. The gcj runtime doesn't even get consulted.
>
> Andrew -- I think there might be some confusion. I tried to keep
> the two subjects as separated as possible, but perhaps I failed
> (or I succeeded, and I'm just confused :). Further up in this post,
> it reads:
>
> > > > > So, we're talking about my natively compiled binary loading and
> > > > > using some regular old .jar file full of .class files...
>
> but your most recent reply seems to be discussing the case when
> an interpreted Java program is using a natively compiled .jar.so...
>
> I'm supposing that the most common case is when you've got some
> program you want natively compiled, and it relies on n-number of
> jars that you haven't yet even tried to natively compile -- you
> just figure that your natively compiled program will load them as
> necessary like before.
gcj will only try to do that if you use indirect dispatch.
> In that case, when building your app, you just specify your
> --classpath=... and let gcj go off finding these jars that the app
> depends on.
If your app -- the one you're compiling to native code -- simply uses
some classes in a jar file and expects them to be loaded at runtime,
then your'e going to need indirect dispatch.
However, if your app calls ClassLoader.loadClass("C") to get a class C
and then invokes C.newInstance() then that will work. What won't work
is if your natively compiled app does
new C();
See the difference?
> Are you replying under another assumption -- namely, that the natively
> compiled app was linked to mystuff.jar.so ( -lmystuff.jar ) at build-
> time?
No.
Andrew.
