[2.45 PATCH 0/3] Backport GLIBC_ABI version dependencies

[Sam James]

Nick Clifton <nickc@redhat.com> writes:

> Hi Sam,

Hi Nick,

>
>>>> Richard would like to make GCC configure fatal by default unless users
>>>> have safe glibc or explicitly ask for it:
>>>>
>>>> https://inbox.sourceware.org/gcc-patches/CAFiYyc2P5ioY=w2wuHZoa275yLsEKBnnQbGgpkDDys=7x718kA@mail.gmail.com/
>>>>
>>>> This patch set backports GLIBC_ABI version dependencies to 2.45 so that we
>>>> can tell users to use it.
>>>
>>> Nick, for some more context:
>>>
>>> I'll note that we've backported the relevant symbols to appropriate
>>> glibc branches (quite far back) based on discussion there, but we need
>>> the GLIBC_ABI_GNU2_TLS dependency to be added by bfd for this to be useful.
>>>
>>> Coordinating changes across the GNU toolchain isn't easy. But it is a
>>> strength that we can do these things when necessary. My hope is we
>>> can have these backports (even if extraordinary) and possibly have a
>>> 2.45.1 release for:
>>> a) this, and
>>> b) the strip fixes (already on the branch), and
>>> c) the windres fix (already on the branch).
>>>
>>> I've been using these for a while and not had any issues.
>>>
>>> I will also note:
>>> * the GLIBC_ABI_DT_X86_64_PLT change here fixes some confusion that hit
>>>    distributors of glibc (https://sourceware.org/bugzilla/show_bug.cgi?id=33212#c0)
>>>    becausee we were previously abusing GLIBC_2.36 for that;
>>>
>>> * the GLIBC_ABI_GNU_TLS (not the GLIBC_ABI_GNU2_TLS one) change is
>>>    needed to know if binaries are safe even without any default changes
>>>    in GCC for i386 if TLS is used.
>> Gentle ping when you get a chance, Nick. Cheers!
>
> Thanks for the gentle prod, and sorry for missing this thread before.
>
> So I am totally OK with creating a 2.45.1 release.  It is something that
> should only take me a weekend to complete.

Thank you!

>
> Is everything ready on the 2.45 branch now ?  Or should I wait until you
> give me the OK ?

Please wait until I give the OK, I'll check in this series and then
double check we're not missing anything else.

>
> Cheers
>   Nick

thanks,
sam