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

[John M. Gabriele]

--- 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