This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Distributions still suffering from s390 ABI change problems.
- From: Aurelien Jarno <aurelien at aurel32 dot net>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: David Miller <davem at davemloft dot net>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, siddhesh at redhat dot com, allan at archlinux dot org, libc-alpha at sourceware dot org
- Date: Mon, 14 Jul 2014 20:31:23 +0200
- Subject: Re: Distributions still suffering from s390 ABI change problems.
- Authentication-results: sourceware.org; auth=none
- References: <20140713182420 dot GA14513 at hall dot aurel32 dot net> <20140714052022 dot GR609 at spoyarek dot pnq dot redhat dot com> <20140714072228 dot GF1239 at hall dot aurel32 dot net> <20140714 dot 002520 dot 985400136122770421 dot davem at davemloft dot net> <53C40A5A dot 5050202 at redhat dot com>
On Mon, Jul 14, 2014 at 12:50:34PM -0400, Carlos O'Donell wrote:
> On 07/14/2014 03:25 AM, David Miller wrote:
> > From: Aurelien Jarno <aurelien@aurel32.net>
> > Date: Mon, 14 Jul 2014 09:22:28 +0200
> >
> >> We can continue handling this ABI change by rebuilding all packages
> >> dependind on libpng, but I am afraid that embedding a jmp_buf in a
> >> structure is not that uncommon and that we are going to discover
> >> more affected packages.
> >
> > This is a really serious mess.
>
> There was no other way around this, and our tooling sucks for detecting
> mixed ABI usage and telling users how to fix it.
>
> It is documented in the 2.19 release notes here:
> https://sourceware.org/glibc/wiki/Release/2.19#Packaging_Changes
>
> IBM knew this was a serious mess, but for reasons of hardware enablement
> the size had to be extended. There are backwards compatible versions of
> the functions that use these structures, but that's not much consolation
> when we know the structure size is embedded in other structures.
>
> For RHEL we've had to make some very special statements to our customers
> regarding this transition, and we had to rebuild packages to fix this
> issues.
>
> Debian suffers the most because they don't do mass rebuilds.
We did mass rebuild of all perl packages. But mass rebuilds do not
prevent mixing old and new versions of the packages, which has caused
issues on some systems. It also means that all locally built code has to
be rebuilt. How is that handled on RHEL?
We are likely going to handle that by bumping the soname of each
affected libraries just for s390x (we did that for perl). It would have
been easier if the soname of the libc would have been increased, as it
were the ABI change originated.
Also there seems to be a problem in the compatibility symbols, some code
fully compiled against libc 2.18 do not run with libc 2.19, but do run
with libc 2.19 and the change reverted. I *suspect*, but nothing is
confirmed yet, that the compatibility symbols to not handle all cases
of the pthread_cleanup functions.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net