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:
>  > >  > 
>  > >  > [snip]
>  > >  > 
>  > >  > 
>  > 
>  > I thought the whole point of using -findirect-dispatch was when
>  > you compile your mystuff.jar --to--> libmystuff.jar.so, and then,
>  > right after that, to use gcj-dbtool on it so that any apps (natively
>  > compiled or else interpreted) could find and use your
>  > libmystuff.jar.so at runtime when the app asks libgcj for
>  > mystuff.jar.
> 
> That's not the whole point, but it is a convenient feature.

Yes! I see that now. Thanks!


>  > What we've been discussing, and what you're talking about here,
>  > is when, at runtime, a natively compiled app wants to load/use
>  > an actual jar file. What in blazes does it matter whether or not
>  > my app was natively compiled with -findirect-dispatch? Nobody's
>  > trying to use ClassLoader.defineClass() to load my app's classes.
> 
> The key difference is this: with indirect dispatch, gcj uses its own
> mechanism for symbol lookups, whereas without indirect dispatch gcj
> must rely on the operating system's runtime loader.  That runtime
> loader doesn't know how to load jars, but it does know how to load
> shared libraries.

Check.


>  > It's sounding like, if I natively compile my app with indirect
>  > dispatch, and link it with --classpath=/path/to/mystuff.jar, and
>  > run it with $CLASSPATH correctly pointing to that jar, then it buys
>  > me some convenience. I can simply put in my imports, and use the
>  > classes in mystuff.jar just like using java.util.Date.
>  > 
>  > Without indirect dispatch, I've guess I've got to use
>  > loadClass("MyFooClass"), then "MyFooClass.newInstance()"
>  > (which I have to have implemented beforehand)... but
>  > I don't see the difference between
>  > "MyFooClass.newInstance()" and "new MyFooClass()".
> 
> But they are different.

Yes. I see. When you call the ctor, you're asking the runtime
to do its trick of automatically dynamically loading the class/jar.


>  > Earlier, you mentioned:
>  > > > [snip] 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.
>  > 
>  > I still don't know why you wrote that. When natively compiling
>  > my Java app, I wouldn't be specifying any -lanything,
> 
> Well, that's your call.  Using -lfoo is a perfectly reasonable thing
> to do though, and it will work without indirect dispatch.

Right. I was still thinking of the case when your natively compiled
app needs to dynamically load all sorts of jars, and you don't want
to worry about natively compiling all of them. Check.


>  > but rather, I'd be using --classpath=/path/to/mystuff.jar. If it
>  > compiles and links without needing any extra .so's, why would ld.so
>  > go looking for stuff that I never told it my app needed?
> 
> It wouldn't.  But if you did use -lfoo, then that would work.
> 
> Andrew.
> 

Sweet. Thanks for the point-by-point reply Andrew. Much appreciated. :)

---John



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs