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

[Mike Frysinger <vapier at gentoo dot org>]

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: signature.asc
Description: Digital signature