Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's-mfloat-abi=hard ABI.

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, May 7, 2012 at 2:47 PM, Roland McGrath <roland@hack.frob.com> wrote:
> I don't really recall, but I suspect that the reason for -undef may have
> been just the default predefines like "i386" or "linux" causing problems.
>
> Possibly there once was a principle that this mechanism should only be
> used for testing things we defined in config.h or other such places
> rather than predefines--the same general principle by which we prefer
> sysdeps file selection to #ifdef on predefines. ?But here we have a case
> where using the predefine seems sensible enough. ?There's no need to
> enforce such a philosophy mechanically so it constrains all cases. ?We
> can just do it socially through code review, to constrain reliance on
> predefines to the very few cases where we really think it's the wise choice.
>
> Just dropping -undef will break things by replacing all "linux" with "1"
> and so forth. ?In some trivial experiments on my random system version of
> GCC, -std=c99 or -std=c89 does not eliminate the nonstandard predefines
> (non-__ names), but -ansi does--despite the GCC manual's claim that -ansi
> is equivalent to -std=c89. ?So we could use -ansi instead of -undef,
> though that feels a little icky because it's so nonobvious (and contrary
> to documentation) that this is what has that effect.

Using -ansi instead of -undef seems like a bad idea even if it would
fix the problem at hand.

> Conversely, I can see a doing a generalized version of configure-time
> tests for predefines. ?i.e.
> ? ? ? ?GLIBC_CHECK_PREDEFINE([__ARM_PCS_VFP])
> would expand to a check that adds __ARM_PCS_VFP to an extra config.h-like
> file (or maybe just a config.make variable, for simplicity at the cost of
> full dependency tracking goodness) if predefined at configure time.

I agree, that sounds like a good solution e.g. a glibc specific macro
that does a little more than AC_EGREP_CPP provides.

For avoidance of doubt I'm not going to go that route for this change,
but I did file a bugzilla ticket to look into a cleanup of
config.in.h.

Cheers,
Carlos.