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. That's why it felt like a decent compromise (perhaps including --with-glibc-version adjustments as I mentioned upthread). On the other hand, I am sympathetic to the argument that the test as-written is not intuitive because of what you say below. A flag-day approach for 16 combined with guidance for those targeting older glibcs to set a --with-glibc-version=too-old (like 2.41) would work for us, but it's not so good for others where they're tracking glibc release branches yet using latest GCC. H.J. felt strongly about not having those users miss out, and I tend to agree. > > 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, not just for building GCC, but I accept that's not a reason by itself to introduce more such tests. sam
