BC ABI (was "Re: [fedora-java] Re: Java OpenGL on FC4")

[Andrew Haley]

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.