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

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi Paolo,
> I don't have an opinion on this; however, I would like to point out that
> the check is already centralized, though in config/.  The purpose of the
> toplevel configure is *not* to have tests performed for all submodules
> (BTW, this would be possible only for build/host checks; target checks
> would have to wait for gcc to be built), but to find tools and to decide
> what to build.
>
> In this respect, checks for the prerequisites of GCC (like GMP or an Ada
> compiler) are already borderline.  They are present there just because
> you'd rather see the compilation fail at configure time, not at make
> time, if the problem is that prerequisite packages are missing.
>   
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...
> > > As per our earlier discussions, I think the libstdc++ "smart"-ness is a
> > > mistake.  We have a good method for probing the C library: link-time
> > > tests.  We don't use it for libstdc++ only because some people use a
> > > build procedure in which you can't link C programs by the time you're
> > > building the C++ library.  I suspect the other library maintainers just
> > > didn't worry about that scenario.
> > >       
> I think we can provide a --disable-link-tests to preserve this behavior
> for people that find it interesting.  We can have a deprecation period.
>   
Humm... Certainly there is an inconsistency between the way libstdc++ 
uses that test and the other three cases, which we should resolve. I'm 
not sure to understand how --disable-link-tests would help about that. 
Is it something that would be essentially used only by libstdc++-v3? 
Would it be used by its checks also doing link tests to avoid hard 
failures of configure with "link tests not allowed after..."? In that 
case maybe people could just pass --disable-tls when building, as they 
have to do anyway for the other libraries...

On one side, this issue with link-tests in libstdc++-v3 is very easy, 
just align the library to the other libraries in the way it uses 
GCC_CHECK_TLS & co, assume the people will just disable by hand tests 
trying to do link tests, and be done with it. On the other hand, we had 
*forever* this dogma of not running link-tests when non-native and seems 
strange that getting rid of it will not cause problems or unhappy people...
> OTOH, I am also in favor of removing it at least by default.  Nowadays,
> people build GCC with C-only support, then libc, then rebuild GCC.
> Also, as a single data point, a friend just wrote me last week because
> he was puzzled by the libstdc++ cross-compilation configuration and
> couldn't get it to work. :-)
>   
Ok, let's try to make those people happier for 4.4.0...

To summarize the present discussion, I'm thinking we should do two, or 
maybe three things:
 1- Run GCC_CHECK_TLS unconditionally, as the other libraries do.
 2- Also run unconditionally GCC_CHECK_UNWIND_GETIPINFO and AM_ICONV, 
but in my opinion these tests should get a parameter for people that 
want to disable the check by hand (or set its value by hand too?). 
Probably I need help about this one: isn't libstdc++-v3 code, I'm not 
sure the build system maintainers agree about the details of the idea...
 3- The change should be explained in the release notes.

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

Paolo.