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

[Roland McGrath <roland at hack dot frob dot com>]

> 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