This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]