[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Handling s390 libc ABI change in Debian

Hi all,

glibc 2.19 has changed the libc ABI on s390, more specifically the
setjmp/longjmp functions [1] [2]. Symbol versioning is used to handle
some cases, but it doesn't work when a jmp_buf variable is embedded
into a structure, as it changes the size of the structure. The result
is that mixing programs or libraries built with 2.18 with ones built
with 2.19 do not work anymore, usually they end up with a segmentation
fault. Some persons from this list have experienced that with perl.

We first thought it was limited to a few packages (even if all perl is
already more than that), but as time goes more and more issues are
found. libpng and gauche are also affected, the issue with mono is
also likely due to this ABI change.

According to upstream [3], the problem is that Debian doesn't do a mass
rebuild, which is the strategy chosen by Red Hat to handle^Wworkaround
this issue. This means some programs might segfault during the upgrade,
or on partially upgraded systems.

Now we have to chose a strategy for Debian. I see multiple options:

1) Ignore the issue and just rebuild (binNMU) the packages that seems
affected when we discover them. This means partial upgrades will likely
be broken, and that we might discover some broken packages only after
the jessie release.

2) Rebuild (binNMU) all packages. This means partial upgrades will
likely be broken.

3) Bump the soname of affected packages and rebuild their reverse
dependencies. It is the solution that is currently being implemented for
perl. It clearly won't scale if more broken packages (and even for
libpng) are discovered as it requires a source upload and a transition
handled by the release team. It also means breaking the ABI compatibility
with other distributions.

4) Bump the libc soname to libc.so.6.1 and do a libc transition. This is
probably what upstream should have done instead of breaking the ABI.
This is a huge work though, and this also means breaking the ABI
compatibility with other distributions.

5) Revert the ABI change. This is likely just postponing the problem as
the change is required to support future hardware. This also means
breaking the ABI compatibility with other distributions.

6) simply drop the s390x port and tell users to either use an other
distribution or use Debian on other hardware.

Any opinion? Any other ideas how to handle that?


[1] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ee4ec1d7f9bdbdfc87117133478cfb2f6653e65c
[2] https://sourceware.org/glibc/wiki/Release/2.19#Packaging_Changes
[3] https://sourceware.org/ml/libc-alpha/2014-07/msg00316.html

Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: Digital signature

Reply to: