From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26769 invoked by alias); 20 Nov 2014 21:12:20 -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 26682 invoked by uid 89); 20 Nov 2014 21:12:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Date: Thu, 20 Nov 2014 21:12:00 -0000 From: Mike Frysinger To: Joseph Myers Cc: libc-alpha@sourceware.org, roland@hack.frob.com Subject: Re: [PATCH] arm: do not abort EABI check for bootstrapping Message-ID: <20141120211215.GE3743@vapier.wh0rd.info> Mail-Followup-To: Joseph Myers , libc-alpha@sourceware.org, roland@hack.frob.com References: <1416468692-4317-1-git-send-email-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/2994txjAzEdQwm5" Content-Disposition: inline In-Reply-To: X-SW-Source: 2014-11/txt/msg00564.txt.bz2 --/2994txjAzEdQwm5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2971 On 20 Nov 2014 20:42, Joseph Myers wrote: > On Thu, 20 Nov 2014, Mike Frysinger wrote: > > The change to simplify the EABI/OABI check from a tuple to a compile te= st > > broke the ability to bootstrap a cross-compiler when generating the gli= bc > > 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. >=20 > I don't see a reason to treat this test any differently from many other=20 > configure tests - we expect a working compiler, but may or may not fail=20 > configure if the breakage is such that no compiler >=3D GCC 4.6 should fa= il=20 > the test (in such cases, we don't actually need to have configure tests). >=20 > The ideal bootstrap procedure we're aiming for is as described at=20 > . We don't=20 > quite have it, but only in that GCC needs reconfiguring and rebuilding fo= r=20 > step 5: a basic GCC with static-only libgcc (configured in a way that=20 > causes inhibit_libc to be defined) can build glibc, and the resulting=20 > glibc is identical to one built after an alternating series of bootstrap= =20 > GCC and glibc builds, but you need to reconfigure at toplevel to get a GC= C=20 > that can build and use shared libgcc and other libraries. (And also a=20 > glibc build tree built with static-only libgcc may not be able to run the= =20 > testsuite properly; certainly you need a C++-capable compiler to run some= =20 > tests.) thanks, i'd forgotten about this thread. in Gentoo we support a wide varie= ty of=20 C libraries and versions and compilers, so deviating in overall procedure i= s a=20 pita (especially since this has largely been working w/gcc-3.x+). i know t= hat's=20 not really glibc's problem since the project only concerns itself with the= =20 future. just stating it to vent a bit :p. > > 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 ... >=20 > If we don't think it's realistic for someone to attempt building with an= =20 > OABI compiler and get confused by the failure later in the build, that's = a=20 > possibility. see below > (If anything, failing for non-ARM compilers is a feature - it seems quite= =20 > plausible for someone to attempt building glibc for a different system=20 > without realising they first need to build a cross compiler, or with thei= r=20 > configuration wrong in some way so that the cross compiler isn't used.) i don't see why arm should be special in this regard. none of the other ta= rgets=20 do this. if you configure for a target and you don't have a compiler that = can=20 produce for that, you'll get lots of errors. if this is a use case we thin= k is=20 useful (i don't think it is), we probably should have it be done for everyo= ne=20 and not ad-hoc for arm. -mike --/2994txjAzEdQwm5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUblkvAAoJEEFjO5/oN/WBhHoQALSfbBOuNwtddSJJek/JrHIz AlqM3noDgr1k5TJyjGpxm8ch9twgoOjCdNr0YFEAXpmFqmZq8/ozF5GoUA9l+i6a wnTugN6BA05nBTOKFvB5ZySigwqRMNL0VcN5W1phTuOXiU3ZRQeX3tYRo5xvlH4y hj0Z4bdUYfJ33mqlesvlpfzw1cDGLT6ZF3dwt3mzhfVTslXV2cFDmoDSEJ7NspiB q8CmmjUD2N8YjBTlAV4hGM1LjpIXebHfQkvIs1dL3mSTOiTmbfavd1GzQEv3Zh9t GSt3p6bTXoeJNFaQTwN3eb+DLxt5IxIsuClyJVRQP7kQJ2cZmiE8S9tuEIiP6XDV Qca0ojX+BKLdkO0ylaztIJ4U18BO2GzVxOsyXjJ5kLK+eq/pxrQmF9sHk4y3KRsw bfR5Xi5BpTkGVBD3w3RoybmM5vU2nqkuCNVuifelFqB8jgGD+1Cy6iFGJKqEJnws W1xqxP5qU9ofNvNAMGCX8czPlkFKgu+gdX18nNdI5mbeKY7B1E2aHkZsnRpufTgL b7xubfzVPhZ/C9I2iKsAqJKm5KdqhO34fo934LRDcb9SlDhX1kWzNe5KiP/kglE4 2Z7dStyIY4TZWplIPVB7MP7k6y+nyAAptlEg4BQa4V1PPzt0wnNbAV4cHcTtZKEf IvwzAMEEjPt9B2v5f5MS =+PVa -----END PGP SIGNATURE----- --/2994txjAzEdQwm5--