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? Btw, does mixing of gnu/gnu2 within the same binary work? 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.
