[RFC] Do we care about binary compatibility of code produced by cross-compilers?

[Paolo Bonzini]

Ian Lance Taylor wrote:
>>> ... actually, if all the checks presently doing link-tests consistently
>>> get a parameter allowing to disable the test completely and also to set
>>> its value, I'm thinking with proper documentation nobody could be
>>> *really* unhappy with the change... Do you agree?
>> The cache file is a way to set the value of a test.
> 
> As Paolo B knows, we've historically had problems using a single cache
> file for all directories.  The problem is that different directories
> sometimes have subtly different meanings for the same cache variable.

Yes, I was in a hurry in answering.  However, I remember that the
problems with the single cache file was just race conditions.  Your
memory (and history) is longer than mine, but the optional serializing
of configure-* supported by the toplevel is what remains of the attempts
to use a cache for Autoconf tests.

What I meant with my suggestion is that if people wanted to override the
results of tests, they can use a system-wide cache for the target.  As
Ian knows, :-) Autoconf has a $CONFIG_SITE variable that you can use for
that.  While right now this is explicitly disabled for target libraries
(because it applies to the host system), I suppose a simple patch to add
--with-{build,target}-config-cache=/path/to/config.site would be okay
even in stage3.

For that, I wouldn't care much about conflicting values; in most cases,
anyway, you can use a conservative setting or, since config.cache is
sourced, you can use a case statement.

> I don't think it's worth worrying about the fact that the tests are
> run multiple times.  If you want to speed up configury, help get Tom's
> quagmire project working for gcc (http://code.google.com/p/quagmire/).

Agreed. :-)

Paolo