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

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

[Mike Frysinger]

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.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
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 ...

 sysdeps/arm/preconfigure    | 4 ++++
 sysdeps/arm/preconfigure.ac | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/sysdeps/arm/preconfigure b/sysdeps/arm/preconfigure
index 59d776d..6a4c84e 100644
--- a/sysdeps/arm/preconfigure
+++ b/sysdeps/arm/preconfigure
@@ -7,9 +7,13 @@ arm*)
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
+/* Do not abort when bootstrapping initial glibc headers -- determine that with
+   a basic sanity check.  */
+#ifdef __arm__
 #if !__ARM_EABI__
 #error
 #endif
+#endif
 int
 main ()
 {
diff --git a/sysdeps/arm/preconfigure.ac b/sysdeps/arm/preconfigure.ac
index d78817b..157e822 100644
--- a/sysdeps/arm/preconfigure.ac
+++ b/sysdeps/arm/preconfigure.ac
@@ -4,8 +4,12 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
 case "$machine" in
 arm*)
   AC_TRY_COMPILE([
+/* Do not abort when bootstrapping initial glibc headers -- determine that with
+   a basic sanity check.  */
+#ifdef __arm__
 #if !__ARM_EABI__
 #error
+#endif
 #endif], [], [], [AC_MSG_ERROR([Old ABI no longer supported])])
 
   # If the compiler enables unwind tables by default, this causes
-- 
2.1.3

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

[Roland McGrath]

I have no particular opinion about this one change and it's up to Joseph to
approve it or not.  But it seems quite fragile to tweak individual checks
like this to support some arcane configure-sort-of-works case.  I don't
understand the scenario you are trying to support.  I've never heard of
doing any step with libc without having a compiler at all.  The way I'm
familiar with going about bootstrapping is to do just all-gcc and
install-gcc first, and then build libc.

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On 20 Nov 2014 09:59, Roland McGrath wrote:
> I have no particular opinion about this one change and it's up to Joseph to
> approve it or not.  But it seems quite fragile to tweak individual checks
> like this to support some arcane configure-sort-of-works case.  I don't
> understand the scenario you are trying to support.  I've never heard of
> doing any step with libc without having a compiler at all.  The way I'm
> familiar with going about bootstrapping is to do just all-gcc and
> install-gcc first, and then build libc.

some (many?) targets require some C library headers before they can build for 
the target at all.  we used to do cross-compiling where we'd skip the C library 
headers, but the amount of patching/hacks we had to add to GCC got 
unmaintainable, and the code base got more and more hostile to the concept 
(just search for inhibit_libc).  how exactly are you building the first GCC 
w/out any C library headers ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Roland McGrath]

> some (many?) targets require some C library headers before they can build
> for the target at all.

Not to build the compiler itself or other host tools, only to build the
target libraries.

> how exactly are you building the first GCC w/out any C library headers ?

Just 'make all-gcc'.  It's only things in the 'all-target-*' makefile
targets that need target C library headers.

In the beforetime, the long long ago, the build of libgcc was intertwined
directly with the compiler build.  But for several versions now (all that
we support for building libc, I'm pretty sure), it's just a normal target
library like all the others (libstdc++ et al) in the build system.

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

On 20 Nov 2014 10:36, Roland McGrath wrote:
> > some (many?) targets require some C library headers before they can build
> > for the target at all.
> 
> Not to build the compiler itself or other host tools, only to build the
> target libraries.
> 
> > how exactly are you building the first GCC w/out any C library headers ?
> 
> Just 'make all-gcc'.  It's only things in the 'all-target-*' makefile
> targets that need target C library headers.
> 
> In the beforetime, the long long ago, the build of libgcc was intertwined
> directly with the compiler build.  But for several versions now (all that
> we support for building libc, I'm pretty sure), it's just a normal target
> library like all the others (libstdc++ et al) in the build system.

it is still integrated ... at least, we attempted exactly that in CrOS with 
gcc-4.8 and it was not possible to build libgcc & libstdc++ w/out also building 
the local copy of the compiler.

i'm not sure why we're forcing this from the perspective of glibc.  being able 
to install the C library headers for a target should not require probing the 
assembler/linker/compiler.  the installed headers are the same regardless.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Roland McGrath]

> it is still integrated ... at least, we attempted exactly that in CrOS
> with gcc-4.8 and it was not possible to build libgcc & libstdc++ w/out
> also building the local copy of the compiler.

Oh, yes, that's the case.  (At least, I also didn't find any way to get it
to use a pre-built compiler to build the target libraries, and instead just
gave up and let the gratuitous rebuild of the compiler be part of my "build
the target libraries" step and I just throw away that second build of the
compiler.  But I really didn't fight with the GCC makefiles for all that
long before I gave up.)  But it's not the case that you can't build the
compiler without building the target libraries, so it's not the case that
you cannot get a compiler with which to build libc.

> i'm not sure why we're forcing this from the perspective of glibc.  being
> able to install the C library headers for a target should not require
> probing the assembler/linker/compiler.  the installed headers are the
> same regardless.

That's not necessarily always true, though probably it is in practice and
perhaps it should be by policy.  That is, nowadays we use compiler-based
checks (checking predefines) in some places to contribute to the sysdeps
directory selection.  It could be that which installed sysdeps headers you
get is affected by sysdeps directory choices that were affected by
compiler-based configure checks.  The only checks of this sort I can think
of off hand are for "submodel" sorts of variation, and for x32 (choosing
between ABIs in a tri-arch ABI setup); those are cases where we intend the
installed headers to be universal across the submodels and across the
cooperating ABI sets.  But nothing in the infrastructure ensures that there
cannot be a case where it matters, and I'm not entirely confident off hand
that as a matter of policy we always do or should rule out all such cases.

At any rate, I never said anything about "forcing" anything.  We do have
the install-headers target, after all.  What I said is that the notion of
using arcane tweaks in individual configure checks to support your use case
is too fragile.  We've never claimed to, or tried to, support a "no working
compiler" configuration before.  If we actually want to support that use
case, then we should be explicit about it and find a clean and maintainable
way to do it.  Probably that would be something like an explicit configure
switch (that disables the compatible-compiler check, e.g.) and macros we
use around all of our compiler-based checks (that make them yield the
safest default in the absence of a compiler), but I'm citing the ugliness
and unmaintainability of your approach rather than proposing a specific
alternative right now.


Thanks,
Roland

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

[Joseph Myers]

On Thu, 20 Nov 2014, Roland McGrath wrote:

> That's not necessarily always true, though probably it is in practice and
> perhaps it should be by policy.  That is, nowadays we use compiler-based
> checks (checking predefines) in some places to contribute to the sysdeps
> directory selection.  It could be that which installed sysdeps headers you
> get is affected by sysdeps directory choices that were affected by
> compiler-based configure checks.  The only checks of this sort I can think
> of off hand are for "submodel" sorts of variation, and for x32 (choosing
> between ABIs in a tri-arch ABI setup); those are cases where we intend the
> installed headers to be universal across the submodels and across the
> cooperating ABI sets.  But nothing in the infrastructure ensures that there
> cannot be a case where it matters, and I'm not entirely confident off hand
> that as a matter of policy we always do or should rule out all such cases.

There are some cases where submodel variation does affect the installed 
headers.  At least:

* m68k bits/fenv.h and bits/mathinline.h.

* sh bits/mathdef.h.

(I think these should be fixed.)

There are other cases where it may look like submodel variation could 
affect the headers but actually the variants in different sysdeps 
directories are identical (e.g. sysdeps/s390/s390-32/bits/wordsize.h and 
sysdeps/s390/s390-64/bits/wordsize.h - which exist because of the sysdeps 
directory ordering issue described in 
<https://sourceware.org/ml/libc-alpha/2014-03/msg00588.html>).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 4284 bytes --]

On 20 Nov 2014 12:54, Roland McGrath wrote:
> > it is still integrated ... at least, we attempted exactly that in CrOS
> > with gcc-4.8 and it was not possible to build libgcc & libstdc++ w/out
> > also building the local copy of the compiler.
> 
> Oh, yes, that's the case.  (At least, I also didn't find any way to get it
> to use a pre-built compiler to build the target libraries, and instead just
> gave up and let the gratuitous rebuild of the compiler be part of my "build
> the target libraries" step and I just throw away that second build of the
> compiler.  But I really didn't fight with the GCC makefiles for all that
> long before I gave up.)  But it's not the case that you can't build the
> compiler without building the target libraries, so it's not the case that
> you cannot get a compiler with which to build libc.

so from glibc's perspective, "not our problem" ;)

> > i'm not sure why we're forcing this from the perspective of glibc.  being
> > able to install the C library headers for a target should not require
> > probing the assembler/linker/compiler.  the installed headers are the
> > same regardless.
> 
> That's not necessarily always true, though probably it is in practice and
> perhaps it should be by policy.  That is, nowadays we use compiler-based
> checks (checking predefines) in some places to contribute to the sysdeps
> directory selection.  It could be that which installed sysdeps headers you
> get is affected by sysdeps directory choices that were affected by
> compiler-based configure checks.  The only checks of this sort I can think
> of off hand are for "submodel" sorts of variation, and for x32 (choosing
> between ABIs in a tri-arch ABI setup); those are cases where we intend the
> installed headers to be universal across the submodels and across the
> cooperating ABI sets.  But nothing in the infrastructure ensures that there
> cannot be a case where it matters, and I'm not entirely confident off hand
> that as a matter of policy we always do or should rule out all such cases.

true, the sysdeps angle throws a bit of a wrench in there.  we're inconsistent 
though as to how we probe.  some check CPP defines, some check the tuple, some 
check compiler flags, or a combination thereof.

> At any rate, I never said anything about "forcing" anything.  We do have
> the install-headers target, after all.  What I said is that the notion of
> using arcane tweaks in individual configure checks to support your use case
> is too fragile.  We've never claimed to, or tried to, support a "no working
> compiler" configuration before.  If we actually want to support that use
> case, then we should be explicit about it and find a clean and maintainable
> way to do it.  Probably that would be something like an explicit configure
> switch (that disables the compatible-compiler check, e.g.) and macros we
> use around all of our compiler-based checks (that make them yield the
> safest default in the absence of a compiler), but I'm citing the ugliness
> and unmaintainability of your approach rather than proposing a specific
> alternative right now.

i certainly cannot disagree with the specific fragiliness of my proposed change.  
the difference with this check compared to just about every other one is that it 
lacks a cache var wrapping as well as fallback logic.  the pattern seen in the 
codebase is largely:
  AC_CACHE_CHECK(blah blah, libc_cv_foo, [
      [...do the compile/whatever test...], [],
      [libc_cv_foo=yes], [libc_cv_foo=no]])
if there is an error triggering, it's after the cache var has been loaded, so we 
can force the knob in the right direction.

the change in this file was done under the heading of simplification where the 
supposition is that checking CPP defines is more reliable than the target tuple.  
but if binutils & gcc (and glibc in some places) hard require the form of the 
tuple in order to get certain behavior, why should we be different ?  checking 
the tuple for *-gnueabi is certainly faster than compiling code :).

i would like to see an option like "only install headers", but it would mean 
trusting the information encoded in the tuple which the commit here specifically 
moved away from.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Joseph Myers]

On Thu, 20 Nov 2014, Mike Frysinger wrote:

> i would like to see an option like "only install headers", but it would mean 
> trusting the information encoded in the tuple which the commit here specifically 
> moved away from.

In general I think we should trust tuples *less* - it should be possible 
to configure glibc with the same tuple as used for GCC (so, for example, 
i686-*-linux-gnu and x86_64-*-linux-gnu should both work for building both 
32-bit and 64-bit glibc - much like for MIPS we examine the value of 
_MIPS_SIM to determine the ABI being built for).  (I also think all cases 
that can use the same tuple with GCC should install the same headers.)

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On 20 Nov 2014 21:35, Joseph Myers wrote:
> On Thu, 20 Nov 2014, Mike Frysinger wrote:
> > i would like to see an option like "only install headers", but it would mean 
> > trusting the information encoded in the tuple which the commit here specifically 
> > moved away from.
> 
> In general I think we should trust tuples *less* - it should be possible 
> to configure glibc with the same tuple as used for GCC (so, for example, 
> i686-*-linux-gnu and x86_64-*-linux-gnu should both work for building both 
> 32-bit and 64-bit glibc - much like for MIPS we examine the value of 
> _MIPS_SIM to determine the ABI being built for).  (I also think all cases 
> that can use the same tuple with GCC should install the same headers.)

i'm aware you can do multilib, but you'd still have to configure glibc with the 
right tuple in order for it to behave correctly.  this is how every autotool
package works and i'm not sure how making glibc special here is useful.  i'm not 
sure it's even feasible unless we avoid autotools entirely.

e.g. ./configure --host=i686-pc-linux-gnu CC="x86_64-pc-linux-gnu-gcc -m32"
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Andreas Schwab]

Mike Frysinger <vapier@gentoo.org> writes:

> i'm aware you can do multilib, but you'd still have to configure glibc with the 
> right tuple in order for it to behave correctly.  this is how every autotool
> package works and i'm not sure how making glibc special here is useful.  i'm not 
> sure it's even feasible unless we avoid autotools entirely.

The gcc target libraries are configured using the same tuple for all
multilibs.  But they need to be aware of this situation.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Roland McGrath]

> so from glibc's perspective, "not our problem" ;)

That was also so.  What I pointed out is that it's also only a problem for
you because you decided it was.  You can instead just decide not to care
about the gratuitous rebuild of the compiler.

> i certainly cannot disagree with the specific fragiliness of my proposed
> change.  the difference with this check compared to just about every
> other one is that it lacks a cache var wrapping as well as fallback
> logic.

I'd certainly have no objection to a change to wrap AC_CACHE_CHECK around it.

> the change in this file was done under the heading of simplification
> where the supposition is that checking CPP defines is more reliable than
> the target tuple.  

It is so in the sense of long-term maintainability.  If what we care about
is how the compiler is behaving, then checking the compiler keeps it
proximate rather than one or (many) more steps removed from where the
actual decision is made.  The exact meanings of tuples change over time,
and some packages are more sensitive than others to the exact tuple.

> but if binutils & gcc (and glibc in some places) hard require the form of
> the tuple in order to get certain behavior, why should we be different ?
> checking the tuple for *-gnueabi is certainly faster than compiling code
> :).

binutils has no other target-specific prerequisite to go on.  GCC has none
but binutils.

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

[Joseph Myers]

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

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

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH] arm: wrap EABI check with a cache var

[Mike Frysinger]

This way people can force the test one way or the other.  It also matches
the style in other configure flags where tests are wrapper in cache vars.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
tested:
	../configure --host=armv7a-jalsjdf-linux-gnueabi -> fail
	libc_cv_arm_eabi=yes ../configure --host=armv7a-jalsjdf-linux-gnueabi -> pass
	libc_cv_arm_eabi=no ../configure --host=armv7a-jalsjdf-linux-gnueabi -> fail
	../configure --host=armv7a-unknown-linux-gnueabi -> pass
	libc_cv_arm_eabi=yes ../configure --host=armv7a-unknown-linux-gnueabi -> pass
	libc_cv_arm_eabi=no ../configure --host=armv7a-unknown-linux-gnueabi -> fail

 ChangeLog                   |  6 ++++++
 sysdeps/arm/preconfigure    | 17 ++++++++++++++---
 sysdeps/arm/preconfigure.ac |  7 ++++++-
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2fa59cf..f1db041 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2014-11-20  Mike Frysinger  <vapier@gentoo.org>
+
+	* sysdeps/arm/preconfigure.ac: Wrap EABI check in a libc_cv_arm_eabi
+	cache var.
+	* sysdeps/arm/preconfigure: Regenerate.
+
 2014-11-19  Carlos O'Donell  <carlos@redhat.com>
 	    Florian Weimer  <fweimer@redhat.com>
 	    Joseph Myers  <joseph@codesourcery.com>
diff --git a/sysdeps/arm/preconfigure b/sysdeps/arm/preconfigure
index 59d776d..c99a412 100644
--- a/sysdeps/arm/preconfigure
+++ b/sysdeps/arm/preconfigure
@@ -4,7 +4,12 @@
 case "$machine" in
 arm*)
 
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC supports ARM EABI" >&5
+$as_echo_n "checking whether $CC supports ARM EABI... " >&6; }
+if ${libc_cv_arm_eabi+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
 #if !__ARM_EABI__
@@ -19,11 +24,17 @@ main ()
 }
 _ACEOF
 if ac_fn_c_try_compile "$LINENO"; then :
-
+  libc_cv_arm_eabi=yes
 else
-  as_fn_error $? "Old ABI no longer supported" "$LINENO" 5
+  libc_cv_arm_eabi=no
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_arm_eabi" >&5
+$as_echo "$libc_cv_arm_eabi" >&6; }
+  if test "$libc_cv_arm_eabi" != yes; then
+    as_fn_error $? "Old ABI no longer supported" "$LINENO" 5
+  fi
 
   # If the compiler enables unwind tables by default, this causes
   # problems with undefined symbols in -nostdlib link tests.  To
diff --git a/sysdeps/arm/preconfigure.ac b/sysdeps/arm/preconfigure.ac
index d78817b..3fe8e9c 100644
--- a/sysdeps/arm/preconfigure.ac
+++ b/sysdeps/arm/preconfigure.ac
@@ -3,10 +3,15 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
 
 case "$machine" in
 arm*)
+  AC_CACHE_CHECK(whether $CC supports ARM EABI,
+		 libc_cv_arm_eabi, [dnl
   AC_TRY_COMPILE([
 #if !__ARM_EABI__
 #error
-#endif], [], [], [AC_MSG_ERROR([Old ABI no longer supported])])
+#endif], [], [libc_cv_arm_eabi=yes], [libc_cv_arm_eabi=no])])
+  if test "$libc_cv_arm_eabi" != yes; then
+    AC_MSG_ERROR([Old ABI no longer supported])
+  fi
 
   # If the compiler enables unwind tables by default, this causes
   # problems with undefined symbols in -nostdlib link tests.  To
-- 
2.1.3

Re: [PATCH] arm: wrap EABI check with a cache var

[Joseph Myers]

On Thu, 20 Nov 2014, Mike Frysinger wrote:

> This way people can force the test one way or the other.  It also matches
> the style in other configure flags where tests are wrapper in cache vars.

OK, though I don't think overriding the results of tests in order to 
configure with a wrong-target compiler (or no compiler) is sensible.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] arm: wrap EABI check with a cache var

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On 20 Nov 2014 22:52, Joseph Myers wrote:
> On Thu, 20 Nov 2014, Mike Frysinger wrote:
> > This way people can force the test one way or the other.  It also matches
> > the style in other configure flags where tests are wrapper in cache vars.
> 
> OK, though I don't think overriding the results of tests in order to 
> configure with a wrong-target compiler (or no compiler) is sensible.

i'd be fine with deleting the check altogether :)
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH v3] arm: drop EABI check

[Mike Frysinger]

GCC marked OABI obsolete in 4.7 and dropped OABI it in 4.8.  So the
number of people this is catching is shrinking every day.  At this
point, it's not terribly useful, so just drop it.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 ChangeLog                   |  5 +++++
 sysdeps/arm/preconfigure    | 22 ----------------------
 sysdeps/arm/preconfigure.ac |  5 -----
 3 files changed, 5 insertions(+), 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2fa59cf..632990e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2014-11-20  Mike Frysinger  <vapier@gentoo.org>
+
+	* sysdeps/arm/preconfigure.ac: Delete EABI check.
+	* sysdeps/arm/preconfigure: Regenerate.
+
 2014-11-19  Carlos O'Donell  <carlos@redhat.com>
 	    Florian Weimer  <fweimer@redhat.com>
 	    Joseph Myers  <joseph@codesourcery.com>
diff --git a/sysdeps/arm/preconfigure b/sysdeps/arm/preconfigure
index 59d776d..33e9501 100644
--- a/sysdeps/arm/preconfigure
+++ b/sysdeps/arm/preconfigure
@@ -3,28 +3,6 @@
 
 case "$machine" in
 arm*)
-
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-
-#if !__ARM_EABI__
-#error
-#endif
-int
-main ()
-{
-
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-
-else
-  as_fn_error $? "Old ABI no longer supported" "$LINENO" 5
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-
   # If the compiler enables unwind tables by default, this causes
   # problems with undefined symbols in -nostdlib link tests.  To
   # avoid this, add -fno-unwind-tables here and remove it in
diff --git a/sysdeps/arm/preconfigure.ac b/sysdeps/arm/preconfigure.ac
index d78817b..20de5bc 100644
--- a/sysdeps/arm/preconfigure.ac
+++ b/sysdeps/arm/preconfigure.ac
@@ -3,11 +3,6 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
 
 case "$machine" in
 arm*)
-  AC_TRY_COMPILE([
-#if !__ARM_EABI__
-#error
-#endif], [], [], [AC_MSG_ERROR([Old ABI no longer supported])])
-
   # If the compiler enables unwind tables by default, this causes
   # problems with undefined symbols in -nostdlib link tests.  To
   # avoid this, add -fno-unwind-tables here and remove it in
-- 
2.1.3

Re: [PATCH v3] arm: drop EABI check

[Joseph Myers]

On Fri, 21 Nov 2014, Mike Frysinger wrote:

> GCC marked OABI obsolete in 4.7 and dropped OABI it in 4.8.  So the
> number of people this is catching is shrinking every day.  At this
> point, it's not terribly useful, so just drop it.

OK.

-- 
Joseph S. Myers
joseph@codesourcery.com