[fedora-java] Re: Native code not loaded when it is in the db

[Andrew Haley]

Andrew Overholt writes:
 > 
 > I have natively-compiled all of Eclipse and created .db files and merged
 > them all into the system-wide .db.  I have verified that the .db file that
 > is being used by gij (this is a gcc that I have built from 4.0 branch head)
 > contains the .jar,.jar.so combinations that I want to use.  However, two of
 > the jars are being loaded as bytecode when I want them to be loaded from
 > their corresponding .so (as evidenced by the following).
 > 
 > eclipse -vmargs -verbose:
 > 
 > [...]
 > [Loaded (bytecode) org.eclipse.core.resources.ResourcesPlugin from (file:/home/andrew/work/eclipse/binary/eclipse/plugins/org.eclipse.core.resources_3.1.0.jar <no certificates>)]
 > [...]
 > 
 > I wrote a little test app (attached) to generate the byte strings from a
 > jar just like they are presented by gcj-dbtool -l (*) so that I could
 > verify that the actual classes I'm interested in are in fact in the .db.
 > This is what I get:
 > 
 > java MD5Test /home/andrew/work/eclipse/binary/eclipse/plugins/org.eclipse.core.resources_3.1.0.jar 
 > [...]
 > org/eclipse/core/resources/ResourcesPlugin.class -> 617779565aed3728932e63a591ad9d
 > [...]
 > 
 > and
 > 
 > gcj-dbtool -l `gcj-dbtool -p`
 > [...]
 > [21443] 617779565aed3728932e63a591ad9d -> /home/andrew/work/eclipse/native-3.1reallyclean/org.eclipse.core.resources_3.1.0.jar.so
 > [...]
 > 
 > (I have verified that my test program run on another jar that loads classes
 > that are BC-compiled has matching signatures to those in the .db)
 > 
 > Interestingly enough, when I try the same jar but with some modifications
 > (I edited some classes in Eclipse, re-generated the jar, and
 > natively-compiled it in the same way I did the above), its classes *are*
 > loaded from the .so.  This leads me to believe that something's either
 > wrong with this jar/.jar.so or with the part of gij that intercepts class
 > loading to feed stuff from .jar.sos in the .db.  Any ideas?

I suspect that there is something wrong with the .so.  Perhaps, for
example, it has some unresolved symdols.  In that case we silently
fall back to the .jars.

It would be nice if verbose:class indicated that it had tried to load
a class from a .so and failed.

 > I guess Eclipse could be loading these two jars in unique ways.
 > The second jar is SWT which I know has JNI .sos ripped out the
 > first time it is used so maybe that is causing some weirdness
 > there?
 > 
 > Thanks,
 > 
 > Andrew
 > 
 > * it would be nice if gcj-dbtool could have this functionality but I guess
 >   then it'll need to store the original classname ... perhaps I'll write a
 >   patch

Something like gcj-dbtool -<?> foo.jar.  Yes, that'd be nice.

Andrew.