This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

In the particular case of config/tls.m4, there is no reason for it to
use AC_LINK_IFELSE in this case:

      [dnl This is the cross-compiling case. Assume libc supports TLS if the
       dnl binutils and the compiler do.
       AC_LINK_IFELSE([__thread int a; int b; int main() { return a = b; }],
		      [gcc_cv_have_tls=yes], [gcc_cv_have_tls=no])
      ]

That should be changed to use AC_COMPILE_IFELSE.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]