--- Andrew Haley <aph@xxxxxxxxxx> wrote: > John M. Gabriele writes: > > > > > > --- Andrew Haley <aph@xxxxxxxxxx> wrote: > > > > > John M. Gabriele writes: > > > > > > > > > > > > --- Bryce McKinlay <mckinlay@xxxxxxxxxx> 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
