Richard Biener <richard.guent...@gmail.com> writes: > On Wed, Sep 3, 2025 at 9:34 PM Sam James <s...@gentoo.org> wrote: >> >> Richard Biener <richard.guent...@gmail.com> writes: >> >> > On Thu, Aug 28, 2025 at 9:14 PM Sam James <s...@gentoo.org> wrote: >> >> >> >> Joseph Myers <josmy...@redhat.com> writes: >> >> >> >> > On Thu, 28 Aug 2025, Sam James wrote: >> >> > >> >> >> Joseph Myers <josmy...@redhat.com> 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 > > Huh. So we're relying on GLIBC_ABI_GNU2_TLS now? Does that > even "work" when the dynamic loader knows nothing about it?
It works fine, the only issue is if you build a binary against a glibc with the symbol *and* ld which emits the dep (no such released binutils exists yet, we hope to get a 2.45.1 release w/ it) and then try to use that binary with a glibc that lacks the symbol (i.e. exactly what we want). (The dynamic loader has no magic here other than us adding a version dependency in ld.so which we inject into binaries when we see use of TLS in bfd.) So, my hope is, if Nick agrees to do a 2.45.1 release, we go ahead as-is. If not, I don't know what we want to do here (introduce some magic like we had before, punt until GCC 17, or something else). If you have another concept in mind for how you want the UX to be for configure, H.J. and I can try figure something out too. (I appreciate this is a bit of a mess, thanks for the patience; dunno if discussing it at Cauldron might turn out to be easier.) > Btw, does mixing of gnu/gnu2 within the same binary work? Yeah, that's completely fine. > > Richard. > >> >> > >> > 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.
