BC ABI (was "Re: [fedora-java] Re: Java OpenGL on FC4")
John M. Gabriele
john_sips_tea at yahoo.com
Thu Aug 18 18:59:49 UTC 2005
--- Andrew Haley <aph at redhat.com> wrote:
> John M. Gabriele writes:
> >
> >
> > --- Andrew Haley <aph at redhat.com> wrote:
> >
> > > John M. Gabriele writes:
> > > >
> > > >
> > > > --- Bryce McKinlay <mckinlay at redhat.com> wrote:
> > > >
> > > > > John M. Gabriele wrote:
> > > > >
> > > > > >Thanks for the reply Bryce. I used much of it to update the
> > > > > >beginning of:
> > > > > >http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
> > > > > >
> > > > > >
> > > > >
> > > > > Great, thanks for doing this.
> > > >
> > > > NP. :) I'm updating it as we go.
> > > >
> > > > >
> > > > > >It sounds like, to be able to mix interpreted and natively
> > > > > >compiled code at runtime, you need to have compiled your .jars
> > > > > >with the -findirect-dispatch option, right?
> > > > > >
> > > > > >
> > > > >
> > > > > If you want to be able to call interpreted code from native code,
> yes.
> > > >
> > > > So, we're talking about my natively compiled binary loading and
> > > > using some regular old .jar file full of .class files...
> > > >
> > > > I don't get it. As I'm understanding it, if the natively compiled
> code
> > > > makes use of ClassLoader.defineClass(), it should just work right off
> the
> > > > bat without the native code having been built with
> -findirect-dispatch,
> > > > since when it tries to read a bytecode stream from the jar, it'll
> > > > find it there. No fuss, no muss, right?
> > >
> > > Right, that's true. And that will work. However, if your compiled
> > > program does something like
> > >
> > > foo.bar();
> > >
> > > where foo *only* exists in bytecode -- has never been gcj-compiled --
> > > then that will *not* work.
> >
> > *Only* exists in bytecode (if I'm understanding what you mean) is
> > just fine -- since that's what ClassLoader.defineClass() expects,
> > correct? My native code still knows how to deal with bytecode...
> >
> > Hmm. Maybe I'm not understanding what you mean by only existing
> > in bytecode...
> >
> > Is foo an instance of a class defined in the mystuff.jar file?
>
> 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.
>
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. 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.
Are you replying under another assumption -- namely, that the natively
compiled app was linked to mystuff.jar.so ( -lmystuff.jar ) at build-
time?
Thanks for all the help! :)
---John
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
More information about the java-devel
mailing list