http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944
--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot
com> 2011-05-11 10:23:53 UTC ---
On Wed, 11 May 2011, gjl at gcc dot gnu.org wrote:
> I get the following output from configure
>
> *** This configuration is not supported in the following subdirectories:
> target-libmudflap target-libgomp target-libssp target-libiberty
> target-libobjc
> (Any other directories should still work fine.)
>
> And the respective line in the toplevel Makefile reads:
>
> TARGET_CONFIGDIRS = libgcc libquadmath boehm-gc libffi zlib
I think you'll need to debug why that happens. The toplevel configure
script has logic that looks at what runtime libraries are required by what
languages, and disables those that are only required by disabled languages
- and that logic works for me, and I haven't changed it at all. It should
see from java/config-lang.in and go/config-lang.in that libffi is only
needed by those languages, see that neither is being built, and disable
libffi independently of the target.
> With the attached patch applied the result is as expected and stuff looks like
> indicated by Joseph.
I don't think this is appropriate. A basic principle of my changes was
that disabling ${libgcj} is generally not the right thing to do,
especially based on the target architecture (rather than OS), and that any
new disabling should have a comment explaining *why* the feature is
disabled, and pointing to a relevant PR. Furthermore, for new disablings
it's better to set unsupported_languages instead of disabling the
libraries, unless you have some reason why it's useful to build the Java
compiler for this target without the libraries.
In this case, unsupported_languages is already set to include Java because
of the lack of libffi support, so no further change should be needed; as I
said, you need to debug why it doesn't work. It would not be wrong to add
noconfigdirs="$noconfigdirs target-libffi"
in the same case that disables Java for targets not supporting libffi (see
my previous comments that you should be able to override
unsupported_languages with explicit --enable-languages configure options)
but there's still the question of why you're getting boehm-gc and zlib
built for your target.
