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.

sam

Reply via email to