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.