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: Jeff Law <law at redhat dot com>, David Miller <davem at davemloft dot net>
- Cc: krebbel at linux dot vnet dot ibm dot com, roland at hack dot frob dot com, aurelien at aurel32 dot net, siddhesh at redhat dot com, allan at archlinux dot org, libc-alpha at sourceware dot org
- Date: Tue, 15 Jul 2014 01:51:10 -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>
>> As you have already stated, we're already in a pickle because the ABI
>> change has been deployed as libc.so.6
>>
>> So at this point, such a cure may already be worse than the disease.
> Very likely. Numerous folks have made it very clear that a .soname
> bump in the libstdc++ would effectively mean the end of the world.
> It's safe to assume that a soname bump in glibc would be even worse.
Why?
What is the problem?
Is there a bootstrap issue?
Aurelien has found a pthread issue with cleanup handlers that needs
more versioning for jmp_buf, so perhaps with that change we may
fix the lingering issues in the s390 transition to the larger
jmp_buf.
>> Therefore, on the negative side, we might be stuck with this. But, on
>> the positive side, we can refer to this incident next time a similar
>> incident arises. We now know exactly what the ramifications are for
>> not handling this properly.
> Right. This is a shining example of the problems in this space.
>
> Either the ABI has to be stable or the soname has to bump, with
> insane amount of pain that entails for the end users. Breaking the
> ABI without the soname bump is the worst of both worlds.
Is it though?
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.
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.
Cheers,
Carlos.