Sam James <[email protected]> writes: > Richard Biener <[email protected]> writes: > >> On Thu, Aug 28, 2025 at 9:14 PM Sam James <[email protected]> wrote: >>> >>> 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. >> >> 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'll implement this scheme. Thanks.
If --with-glibc-version is not passed (or is too low), we want to do whatever check we can. We can check the linker for --gnu2-tls-tag (supporting the option) but that doesn't tell us if glibc has the version tag. Checking if glibc has the version tag requires either: a) using the compiler (because it knows where startup files are), or b) somehow otherwise obtaining the path to, and building, startup files so ld adds the dependency. Using the compiler isn't OK per the rest of the thread. Figuring out where the startup files are, when they may not even be built or exist yet, isn't an option either. I can't inject a fake version dependency and see if it can be resolved, because either the linker would have to resolve it (and then the problem wouldn't exist), or it'd have to be a runtime test (which again isn't appropriate here). If we know a libc (glibc specifically as we're not worried about others for this yet) is available, can we figure out where its startup files are without invoking the compiler? What should I do? We can always simply detect the glibc version and not enable it for backported glibc branches (because we can't safely detect them) but that would be a real shame. H.J., do you have any ideas? sam
