[Bug libffi/48944] build error: "libffi has not been ported to avr-unknown-none."

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.