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. > > 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). -- Joseph S. Myers [email protected]
