From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-179299-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15206 invoked by alias); 8 Jul 2013 08:43:41 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 15175 invoked by uid 89); 8 Jul 2013 08:43:40 -0000
X-Spam-SWARE-Status: No, score=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 08 Jul 2013 08:43:40 +0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r688hd4C004424	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);	Mon, 8 Jul 2013 04:43:39 -0400
Received: from zebedee.pink ([10.3.113.16])	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r688has0030397;	Mon, 8 Jul 2013 04:43:37 -0400
Message-ID: <51DA7BB8.3070301@redhat.com>
Date: Mon, 08 Jul 2013 08:43:00 -0000
From: Andrew Haley <aph@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
CC: Andrew Pinski <pinskia@gmail.com>, Jonathan Wakely <jwakely.gcc@gmail.com>,        Bruce Korb <bruce.korb@gmail.com>,        Andreas Schwab <schwab@linux-m68k.org>, GCC <gcc@gcc.gnu.org>
Subject: Re: fatal error: gnu/stubs-32.h: No such file
References: <51D83AAC.4080200@gmail.com>	<87y59jo6yq.fsf@igel.home>	<51D97472.8010704@gmail.com>	<CAH6eHdSzVcjpVzktBfi6n0cNq=DfBOADAP3BpvTqydmzCFwbCQ@mail.gmail.com>	<CAAiZkiB0W3Lbv63eXcpP6EYhbj-t4DJ=zvFEsSfer_n6nKM_wA@mail.gmail.com>	<CAH6eHdS9v+GyLvVYEjVDbuFtGxwn27-VhqEofykYMe0C_tv9aA@mail.gmail.com>	<CAAiZkiBjh3iR+Gsh2etKRnzO2q=N5iBnXQgwwod4vOELSsbLRA@mail.gmail.com>	<CA+=Sn1=M9_uUHxEV6r0b-0AQE73v=Lv=AgbWwT9nAMuZ=_M7xQ@mail.gmail.com>	<CAAiZkiDnFtgwMQ-LyL1zavp4eHn60krXKh-EKnx74suvXS2CQg@mail.gmail.com>	<CA+=Sn1k33A0-GpTF5Vup786_wcqz5WE_xYhnAPEUyrMTSBKtwQ@mail.gmail.com> <CAAiZkiAxpF=B8k2o8UmWAqKpXzChpQDcm1XhWNxqJNE-ULFF_A@mail.gmail.com>
In-Reply-To: <CAAiZkiAxpF=B8k2o8UmWAqKpXzChpQDcm1XhWNxqJNE-ULFF_A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SW-Source: 2013-07/txt/msg00103.txt.bz2

On 07/08/2013 07:33 AM, Gabriel Dos Reis wrote:
> I strongly disagree.  We (GCC) are at fault here.  We implicitly
> enable a feature at configure time without knowing its builds
> will succeed (despite having repeated reports that it does often
> fail) without much input from the builder (who might be ignorant of
> real reason of failures.) 

That's better than silently disable multilib builds so that the
user doesn't know until the build is complete.  It's better to
abort early.

Andrew.