From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3192 invoked by alias); 8 Jul 2013 15:24:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3179 invoked by uid 89); 8 Jul 2013 15:24:33 -0000 X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,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 15:24:32 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r68FOVsZ027699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Jul 2013 11:24:31 -0400 Received: from zalov.cz (vpn1-6-203.ams2.redhat.com [10.36.6.203]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r68FOTIx020271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 11:24:31 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r68FOSxr011735; Mon, 8 Jul 2013 17:24:28 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r68FOR3i011734; Mon, 8 Jul 2013 17:24:27 +0200 Date: Mon, 08 Jul 2013 15:24:00 -0000 From: Jakub Jelinek To: Bruce Korb Cc: Andrew Pinski , Gabriel Dos Reis , Jonathan Wakely , Andreas Schwab , GCC Subject: Re: fatal error: gnu/stubs-32.h: No such file Message-ID: <20130708152427.GQ2336@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <51D83AAC.4080200@gmail.com> <87y59jo6yq.fsf@igel.home> <51D97472.8010704@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-07/txt/msg00114.txt.bz2 On Mon, Jul 08, 2013 at 08:11:03AM -0700, Bruce Korb wrote: > > But having multilib enabled by default on x86_64 is simply very highly > > desirable, > > REMEMBER: we are talking about having a multilib enableable test in > the configure. If it fails, then it is not enabled by default. This is not > rocket science. It isn't that trivial though, would you do this for native linux configurations only (or how would you handle crosses?), what about --with-sysroot configurations where the system compiler might e.g. not support sysroots, what if the system compiler isn't gcc, or what if it is gcc, but doesn't support multilibs, yet the newly built gcc would be capable of supporting that? So maybe for native configuration without --with-sysroot if system compiler is gcc and a configure test can be compiled successfully when not using any headers with a non-primary multilib option, but a test including some well known glibc header like stdlib.h would fail with an error, error out (silently disabling multilibs would look wrong to me, given that it would be a very problematic heuristics only working sometimes). But, the next question is how to find out what multilib options to pass, if system compiler is gcc, it can check --print-multilib and derive that info from it, but do you have a guarantee that the system gcc multilib support matches the to be built compiler's multilib (e.g., you can have system gcc built on ppc* to default to -m32 and have -m64 as non-default multilib option and configure new gcc to do it the other way around, etc.). Do you still think it is that trivial? Far easier would be if not inhibit_libc to try to compile some trivial program using say stdlib.h include in libgcc configure and error out there, if it isn't for the primary multilib hint that either development support for the non-primary multilib needs to be installed or --disable-multilib used in configure. That would have the disadvantage that the error would show up only after at least first stage of gcc has been built, but would be more reliable. Jakub