From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3929 invoked by alias); 20 Nov 2014 20:42:33 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 3918 invoked by uid 89); 20 Nov 2014 20:42:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Date: Thu, 20 Nov 2014 20:42:00 -0000 From: Joseph Myers To: Mike Frysinger CC: , Subject: Re: [PATCH] arm: do not abort EABI check for bootstrapping In-Reply-To: <1416468692-4317-1-git-send-email-vapier@gentoo.org> Message-ID: References: <1416468692-4317-1-git-send-email-vapier@gentoo.org> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-11/txt/msg00560.txt.bz2 On Thu, 20 Nov 2014, Mike Frysinger wrote: > The change to simplify the EABI/OABI check from a tuple to a compile test > broke the ability to bootstrap a cross-compiler when generating the glibc > headers. At that point, there is no compiler yet, so this compile-time > test will always fail. Wrap the error with a basic sanity check so that > if the compiler fails, we assume this setup. I don't see a reason to treat this test any differently from many other configure tests - we expect a working compiler, but may or may not fail configure if the breakage is such that no compiler >= GCC 4.6 should fail the test (in such cases, we don't actually need to have configure tests). The ideal bootstrap procedure we're aiming for is as described at . We don't quite have it, but only in that GCC needs reconfiguring and rebuilding for step 5: a basic GCC with static-only libgcc (configured in a way that causes inhibit_libc to be defined) can build glibc, and the resulting glibc is identical to one built after an alternating series of bootstrap GCC and glibc builds, but you need to reconfigure at toplevel to get a GCC that can build and use shared libgcc and other libraries. (And also a glibc build tree built with static-only libgcc may not be able to run the testsuite properly; certainly you need a C++-capable compiler to run some tests.) Nothing in this desired procedure involves configuring glibc without having a compiler for the relevant system. > Note: an alternative might be to just delete the EABI check altogether. > It's not like an OABI compiler will be able to properly build glibc ... If we don't think it's realistic for someone to attempt building with an OABI compiler and get confused by the failure later in the build, that's a possibility. (If anything, failing for non-ARM compilers is a feature - it seems quite plausible for someone to attempt building glibc for a different system without realising they first need to build a cross compiler, or with their configuration wrong in some way so that the cross compiler isn't used.) -- Joseph S. Myers joseph@codesourcery.com