Sam James <[email protected]> writes: > 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?
I figured it out, thanks for rubberducking. The test program simply has no libc dependency, it needs one. Disregard. sam
