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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Aurelien Jarno <aurelien at aurel32 dot net>
- Cc: Jeff Law <law at redhat dot com>, David Miller <davem at davemloft dot net>, krebbel at linux dot vnet dot ibm dot com, roland at hack dot frob dot com, siddhesh at redhat dot com, allan at archlinux dot org, libc-alpha at sourceware dot org
- Date: Tue, 15 Jul 2014 03:59:11 -0400
- Subject: Re: Distributions still suffering from s390 ABI change problems.
- Authentication-results: sourceware.org; auth=none
- References: <53C43A5E dot 9020304 at redhat dot com> <20140714 dot 132444 dot 140785163900092398 dot davem at davemloft dot net> <53C440FF dot 3010308 at redhat dot com> <20140714 dot 140948 dot 808129071568411651 dot davem at davemloft dot net> <53C449C0 dot 50709 at redhat dot com> <53C4C14E dot 30908 at redhat dot com> <20140715074223 dot GC32518 at hall dot aurel32 dot net>
On 07/15/2014 03:42 AM, Aurelien Jarno wrote:
> On Tue, Jul 15, 2014 at 01:51:10AM -0400, Carlos O'Donell wrote:
>> I just tested for x86-64 and loading two libc's in a mixed
>> environment results in a completely broken image because the
>> two libc's don't know about eachother and don't coordinate
>> the implmenetation of things like TLS.
>>
>> Therefore I think for libc we can't SONAME bump and we should
>> instead be aiming to detect the incompatible ABI change and
>> simply refuse to run the application.
>
> The idea of bumping the SONAME, is to have two co-existing installations
> of the same architecture, using a different libc. A program would use
> either one or the other. This would make the upgrade process easier and
> allow users to keep the old libc for running old code until everything
> is migrated.
>
> A check to make sure both libc can't be loaded at the same time should
> be added, but for the packages, it should be the responsibility of the
> package manager.
I'd rather extend the .gnu.attributes ABI tags to handle this more
cleanly.
However, either way, you'll now have programs that fail to start during
partial upgrades instead of crashing. Is that any better?
>> For Fedora and RHEL I imagine the pain is that rpm encodes the SONAME
>> as a dependency. Therefore switching to a glibc that doesn't provide
>> the required SONAME means you can no longer build any packages and
>> you have to bootstrap. Given that there is no bootstrap process in
>> place it means manually bootstrapping s390 all over again from scratch
>> for the next major release with a new SONAME for libc. That is a lot
>> of manual work, but it's just work. Fedora should put together a
>> bootstrap process for many other reasons including tools testing.
>
> Indeed, that implies a bootstrap almost like for a new architecture,
> except the manual bootstrap can be done more easily. That's why I talked
> about "huge work" in the other mail.
The s390 SONAME bump is not going to happen because of this.
We have 2.19 out and in the wild. We don't want to bump the SONAME
because of that mistake and the work it generates for s390.
So the best option is to fix the pthread issues, and keep rebuilding
the packages that are broken.
I need to draft policy so that we can do the right thing when this
happens again.
* Don't break ABI ever.
* If you have to break ABI you bump the SONAME.
* Implement .gnu.attributes dynamic loader support and add an ABI
tag for this breakage.
Cheers,
Carlos.