[Patch] Make building without the interpreter work.

[Andrew Haley]

David Daney writes:
 > The current state of the trunk is that if you have a target without ffi 
 > closure support (mips64 for example), you cannot build libgcj.
 > 
 > Some parts of libgcj explicitly test for ffi closure support.  Others 
 > test for interpreter support.  I made the simplifying assumption that 
 > they are the same thing.  That is if the interpreter is disabled, I 
 > assume that ffi closures are not supported.  This seemed quite a bit 
 > simpler than trying to factor these two cases out.
 > 
 > The main change this patch makes is to define a new 
 > AM_CONDITIONAL(INTERPRETER).  This allows entire files to be excluded 
 > from libgcj if the interpreter is not supported.  Then I was able to 
 > conditionally include all jvmti and jdwp files which only are used if 
 > the interpreter is functional.  The remainder of the patch just puts the 
 > jvmti and closure code contained in files that cannot be excluded, 
 > inside of #ifdef INTERPRETER blocks.  Most of this had already been 
 > done, but some has leaked out with the addition of jvmti, jdwp, proxies 
 > and several other libgcj improvements.
 > 
 > With the patch I can build mips64-linux (o32, n32, n64 multi-lib).  With 
 > n32 a Hello World program works, n64 gets a SIGBUS initializing the GC 
 > (I will fix that in a follow on patch).  Also I am currently 
 > bootstrapping and regerssion testing x86_64-pc-linux-gnu.
 > 
 > OK to commit if x86_64-pc-linux-gnu shows no regressions?
 
OK.

IMO, this is of pretty marginal usefulness: a libgcj with no libffi
closure support fails in that important parts of the Java langauge
won't work.  It would IMO have been easier simply to write ffi closure
support for mips64.  

All that allowing a port to build without ffi closures does is provide
the illusion that you have a working libgcj, when in reality you
don't.  However, this is a step on the road to a properly working
port, and for that reason I'll approve it.

Andrew.