This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Toplevel cleanup: disable Java when libffi not supported
- From: Tom Tromey <tromey at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org, bonzini at gnu dot org, dj at redhat dot com, neroden at gcc dot gnu dot org, aoliva at redhat dot com, Ralf dot Wildenhues at gmx dot de, green at redhat dot com
- Date: Fri, 29 Apr 2011 10:26:17 -0600
- Subject: Re: Toplevel cleanup: disable Java when libffi not supported
- References: <Pine.LNX.4.64.1104271547150.13750@digraph.polyomino.org.uk> <Pine.LNX.4.64.1104271632310.13750@digraph.polyomino.org.uk>
>>>>> "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).
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.
Joseph> The ideal would be for information about libffi-supported targets to
Joseph> come from a configure fragment in the libffi/ directory, as per item 4
Joseph> in <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.
This would help libjava's configury as well.
Tom