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. > >> > 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.
