Re: Toplevel cleanup: disable Java when libffi not supported

["Joseph S. Myers" <joseph@codesourcery.com>]

On Fri, 29 Apr 2011, Tom Tromey wrote:

> >>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:
> 
> Joseph> This patch, relative to a tree with
> Joseph> <http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02123.html> applied,
> Joseph> continues the cleanup of toplevel cases relating to disabling Java or
> Joseph> Java libraries by arranging for Java to be disabled (via
> Joseph> unsupported_languages) on targets not supporting libffi
> 
> It does make sense to build libjava without libffi.
> 
> It just means that libjava has somewhat degraded functionality -- libffi
> is needed for the interpreter, for JNI, and for some kinds of reflection
> (Method.invoke).
> 
> I am not sure if there are any existing targets where libjava works but
> libffi does not.  Looking at libjava/configure.host, maybe `arm*-elf'
> (but maybe configure.host is out of data, it is certainly possible).

arm*-elf are targets where libffi's configure thinks it is supported.

> There is also --without-libffi, though; I didn't look to see what your
> patch does with this.
> 
> A better gate for libjava might be boehm-gc.  It is required to run any
> sort of real program.

I should perhaps reiterate that I think the toplevel handles 
unsupported_languages in a suboptimal way.  What it should mean in my view 
is that the languages don't get enabled by default (or by "all" in 
--enable-languages) but can still be enabled by specifying them manually 
in --enable-languages - whereas at present it forces the language to be 
disabled even if the user enables it explicitly.

So Java (and Go) should be disabled by default when libffi isn't 
supported, because they'd try by default to build libffi and so a default 
build will fail.  And much the same applies with boehm-gc.  But if a user 
explicitly enables Java on such a target, libffi should still be disabled 
as unsupported but the front end and other libraries should be built (and 
quite possibly fail).  (Ideally this would have generic logic - for each 
front end, disable it by default if any of the target libraries for that 
language aren't supported.  But that first requires a generic way to get 
information from a library directory about what targets that library 
supports.)

-- 
Joseph S. Myers
joseph@codesourcery.com