This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Distributions still suffering from s390 ABI change problems.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]