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] |
Paolo Carlini <paolo.carlini@oracle.com> writes: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.
Paolo Carlini wrote:Yes, that would be unfortunate. I think it would be better if the gcc
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"
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |