Deprecation of s390-32 in glibc

[Adhemerval Zanella Netto]

On 11/12/25 11:40, Stefan Liebler wrote:
> On 12/2/25 13:41, Stefan Liebler wrote:
>> On 12/2/25 13:07, Florian Weimer wrote:
>>> * Stefan Liebler:
>>>
>>>> The next linux kernel 6.19 is about to remove support for s390-32
>>>> compat layer.
>>>
>>>> Until the code is removed, we of course can also remove
>>>> "s390-linux-gnu" from build-many-glibcs.py script as newer
>>>> kernel-versions don't have the proper syscall-numbers in unistd.h and
>>>> "build-many-glibcs.py update-syscalls" would either fail or would even
>>>> use the syscall numbers from s390-64.
>>>
>>> Is the plan is to remove s390-linux-gnu from build-many-glibcs.py before
>>> we switch the script to Linux 6.19?
>> Linux 6.18 still fully support the s390 compat layer. Yes, I think we
>> should remove s390-linux-gnu from build-many-glibcs.py before/with
>> switching to Linux 6.19. Then the glibc internal syscall numbers for
>> s390-32 are frozen and won't be updated anymore with "update-syscalls".>
>>> But keep the s390-32 subdirectories in the glibc for the time being,
>>> and delete them only at a later stage (presumably in 2027 or even later)?Yes, the s390-32 code is kept in the tree. This allows to build/test
>> glibc with Linux <=6.18 as long as gcc is also able to build s390-32
>> code. As mentioned the glibc 2.45 release (expected February 2027) will
>> be the first glibc release without s390-32 support and the s390-32
>> subdirectories will be removed before this release.>
>>> Thanks,
>>> Florian
>>>
>>
> Are there any other opinions/comments?
> 
> If nobody opposes, we would just handle it this way
Linux 6.19 will be released around February, so s390 will fit into the
ABIs without kernel support for the next glibc release. So I think it 
would be more reasonable to deprecate in the *2.43* and remove on *2.44*
glibc version.