Re: --bootclasspath overriding peer classfiles in a jar

[Andrew Haley <aph at redhat dot com>]

Adam Megacz writes:
 > 
 > Andrew Haley <aph@redhat.com> writes:
 > > What on Earth for?  I can't help if I have no idea what you're trying
 > > to do.
 > 
 > Okay.
 > 
 > - libgcj.jar has the unmodified .class files from libgcj.
 > 
 > - myapp.jar has the .class files from my app
 > 
 > - pruned.jar has all the above .class files (my app and libgcj), but
 >   "unreachable" methods and fields have been removed.  This means that
 >   some method calls are "unresolvable" if you confine your view to
 >   only this jar file.

Right.

 > Before, I was compiling each pruned class file individually, with
 > -fCLASSPATH=libgcj.jar.  So when the compiler saw a reference to a
 > pruned method, it would check libgcj.jar, see the method there, and
 > proceed with the compilation.  The linker would complain about
 > undefined symbols, but I just use --noinhibit-exec and everything
 > works fine.

I don't understand this: if there is a reference to a pruned method in
your application, it'll need to be satisfied or it'll fail at runtime.

 > Currently I'd like to achieve the same effect using jar-at-a-time
 > compilation instead of file-at-a-time.
 > 
 > Any ideas?

If you're not using indirect dispatch, you must compile your code
against a jar file that contains the same classes and methods as the
library you will link against.  This is because method table offsets
must correspond in the jar and the .so.

So, if you prune your libgcj.jar you must prune libgcj.so (or
libgcj.a) in exactly the same way.

It sounds to me like indirect dispatch is what you need.

Andrew.