David Tanzer wrote:
The good news first: it compiles now. The problem I described in the
previous mail was that libjc was linked with the option "-module" (so
it can be dlopen()ed) and this is not portable. I removed the -module
and now it compiles.
I stripped out lots of ELF specific stuff, so my version could be
interesting for a port to windows too. I just don't want to commit it
to "trunk" yet because it's completely untested.
You could create a branch to play with in Subversion. If you do,
I recommend also using svnmerge... http://dellroad.org/svnmerge
@Archie Cobbs: Is the "-module" really important for libjc? If yes we'd
have to find a portable solution for this...
JC dlopen()s itself in order to access core native code for java.lang,
etc. This code in turn accesses core VM functions. It's possible to avoid
this; e.g., you could add a special hack in JC's native linker along with
a static (and redundant) array of available native functions. This would
be easy to do but imposes a maintenance burden because this list must
be kept up to date with the functions defined in libjc/native/*.c.
To make it compile I left the funtion "_jc_dynamic_invoke(...)" in the
file "libjc/arc/ppc/arch_functions.c" empty, but this function is needed
to run JCHEVM (it calls C functions and is needed for JNI AFAICS). Maybe
somebody with more PPC experience can help me with porting this function
from i386.
That function essentially does the same thing as libffi (but slightly
differently of course :-) You might look at libffi's implementation.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
