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

[Paolo Carlini]

Hi,
> Paolo Carlini <paolo.carlini@oracle.com> writes:
>   
>> Paolo Carlini wrote:
>>     
>>> Even more interesting, I would say mysterious, libjava'
>>> configure.ac, like libsdc++-v3', has GCC_NO_EXECUTABLES on top. Do
>>> you understand better than me, what's going on here?
>>>       
>> I think the "solution" of the mystery is that GCC_NO_EXECUTABLES boils
>> down to testing the linker and setting gcc_no_link
>> appropriately. Thus, when cross-compiling, it can well be that the
>> linker works (as I understand it), thus link tests are allowed. Good.
>>
>> Now, if, for some reason, GCC_NO_EXECUTABLES sets gcc_no_link = yes,
>> configuring a cross-compiler library which has GCC_NO_EXECUTABLES on
>> top and GCC_CHECK_TLS somewhere after it fails completely, with "Link
>> tests are not allowed after GCC_NO_EXECUTABLES"
>>     
> Yes, that would be unfortunate.  I think it would be better if the gcc
> tests didn't use AC_LINK_IFELSE, given that magic replacement.  It
> would be better if they used something else which permitted a fallback
> when the linker didn't work.
>   
Today, while replying on the audit trail of bootstrap/37308 I noticed 
tha, for better or worse, GCC_CHECK_TLS is called *4* times, in libgomp, 
libjava, libmudflap, libstdc++-v3.

As far as I can see, among the 4 libraries only libstdc++-v3 tries to be 
"smart" and runs it only when link-tests are always safe to do, when 
native. I find all of this rather puzzling. Shouldn't we run the test 
only once, at toplevel, propagate the information to the libraries, and, 
in case, have an infrastructure which allows the libraries to override 
the toplevel decision? Anyway, something is not at all clear to me in 
our current way of dealing with these issues, explanations from the 
experts very welcome...

Paolo.