From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28175 invoked by alias); 22 Mar 2011 19:51:51 -0000 Received: (qmail 28161 invoked by uid 22791); 22 Mar 2011 19:51:50 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_GC,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Mar 2011 19:51:41 +0000 Received: (qmail 15738 invoked from network); 22 Mar 2011 19:51:39 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Mar 2011 19:51:39 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1Q27cA-0002cs-7S; Tue, 22 Mar 2011 19:51:38 +0000 Date: Tue, 22 Mar 2011 19:51:00 -0000 From: "Joseph S. Myers" To: gcc@gcc.gnu.org, java@gcc.gnu.org cc: hp@axis.com, hp@bitrange.com Subject: Target library disabling at toplevel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00000.txt.bz2 Why do a great many targets disable libgcj by default in the toplevel configure.ac? Where GCC provides a runtime library for a given language, I'd think the compiler isn't particularly useful without the library - and so if the compiler is built for that language, an attempt should be made to build the library, with a build failure if it isn't supported. This is the situation with Go, for example - if you try to build with Go enabled for a target to which libgo hasn't yet been ported, you get a build failure in libgo telling you that the configuration you asked for isn't yet supported. Thus, I'd think that the disabling of libgcj by default on many targets should be removed. If it genuinely doesn't work on a given target, then the right setting is unsupported_languages="$unsupported_languages java" though I'm not sure unsupported_languages works quite the right way (in my view, it should only disable inclusion of a language in --enable-languages=all; if you explicitly specify an unsupported language, it should still try to build it). (And why (CC to maintainer) do some CRIS and MMIX targets list Fortran in unsupported languages? I didn't think the Fortran libraries had any porting issues, unlike Java and Go and Ada.) -- Joseph S. Myers joseph@codesourcery.com