[PATCH] arm: do not abort EABI check for bootstrapping

[Mike Frysinger]

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 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 
> <https://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>.  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.)

thanks, i'd forgotten about this thread.  in Gentoo we support a wide variety of 
C libraries and versions and compilers, so deviating in overall procedure is a 
pita (especially since this has largely been working w/gcc-3.x+).  i know that's 
not really glibc's problem since the project only concerns itself with the 
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 ...
> 
> 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.

see below

> (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.)

i don't see why arm should be special in this regard.  none of the other targets 
do this.  if you configure for a target and you don't have a compiler that can 
produce for that, you'll get lots of errors.  if this is a use case we think is 
useful (i don't think it is), we probably should have it be done for everyone 
and not ad-hoc for arm.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20141120/6ecba21c/attachment.sig>