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

[Paolo Bonzini <bonzini at gnu dot org>]

> I see your point, in particular for checks using the C++ compiler, we
> have many in libstdc++.
> 
> Still, in the case of checks like GCC_CHECK_TLS, if you try to abstract
> a bit from the current strcture of the build system, I'm sure you would
> agree with me that running it 4 times, to obtain exactly the same result
> each time, of course, *is* strange. I have no idea how to implement my
> idea of finding a way to run it only once, at the moment, still...

Not really.  The idea is that in principle there's nothing that prevents
you from building the packages standalone, without the toplevel.  The
toplevel's function is (should be) *purely* to orchestrate the build so
that everything is built with the right environment.

Then of course, some directories are intertwined with gcc so that it
becomes impossible to do so for some modules; these dependencies are of
two kinds:

1) some host modules expect to find other host modules in the tree.  For
example, gcc depends on libiberty, libcpp and build-side fixincludes.
This is not a big deal.

2) some target modules (libada, libgcc, libobjc) used to live in the gcc
directory and they retrieve information from the gcc directory via the
libgcc.mvars file or other means.  This should be considered a bug and
an incomplete transition.

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

Paolo