Richard Biener <[email protected]> writes: > On Thu, Aug 28, 2025 at 9:14 PM Sam James <[email protected]> wrote: >> >> Joseph Myers <[email protected]> writes: >> >> > On Thu, 28 Aug 2025, Sam James wrote: >> > >> >> Joseph Myers <[email protected]> writes: >> >> >> >> > On Thu, 28 Aug 2025, Richard Biener wrote: >> >> > >> >> >> I wonder if we can piggy-back on the existing --with-glibc-version=... >> >> >> somehow? >> >> > >> >> > Indeed, that's the correct way to handle such features so that cross >> >> > compilers default to the same correct configuration as native. >> >> >> >> Do you have a suggestion for how to handle the version tag being >> >> backported to applicable glibc branches? It's not accurate to say >> >> you need glibc 2.42. >> > >> > The --with-glibc-version argument is just a minimum version that's >> > guaranteed to be in use; if an older version number is passed, that >> > doesn't say anything about whether the feature will in fact be supported >> > or not. >> >> Ah, I see. Performing a test is fine when the version is too low, just >> not using the compiler. > > There is always --with-tls. What I'd like to see is GCC 16 defaulting > to TLS2 and > failing configure if: > > 1) --with-glibc-version is too low > 2) whatever test we can do fails > > unless > > --with-tls is present and sets TLS2 or TLS. 2) can degrade to a warning > when TLS2 is forced this way but appears not to work. > > This means we can document GCC 16 defaults to TLS2 on x86-*-gnu-linux > unless explicitly specified with --with-tls=
I have this implemented (needs some small tweaks for non-bfd) [0] but I've not yet posted it because we don't have the changes backported to binutils-2.45 yet. My hope is to get a binutils-2.45.1 release with the backports and I've made the case to Nick for that, I don't know if I'll succeed. If such a release isn't made and we have to wait for binutils-2.46 (which will be ~Feb prob), do we need to punt to GCC 17? Or are we okay with all users on affected targets needing to pass --with-tls=gnu2 unless they're passing old --with-glibc-version=? [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933#c21 > > Richard. > >> > >> >> > The configure tests in this patch use $CC in gcc/configure.ac, which >> >> > can't >> >> > be correct (it's a compiler for the host, not the target, and you can't >> >> > expect a compiler for the target to be available at all in >> >> > gcc/configure - >> >> > building the compiler for the target does not require a previously built >> >> > one to be available). gcc/configure.ac should only use $CC to test host >> >> > properties, not target properties. >> >> >> >> I'll note that we currently do some strange things for linker feature >> >> detection (and the assembler) and encode the results into the compiler, >> > >> > Testing the linker and assembler (for build-x-target) is fine in >> > gcc/configure.ac. It's testing the compiler (for build-x-target) that >> > isn't, since that compiler (and the target libraries / headers) may not be >> > available at all there (the compiler will be built in that directory, >> > there might not be a pre-existing one). >> >> Thanks for explaining. The use of the compiler here is trivial and can >> easily be dropped.
