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: Jeff Law <law at redhat dot com>
- To: "Carlos O'Donell" <carlos 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 13:38:44 -0600
- 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>
On 07/14/14 23:51, Carlos O'Donell wrote:
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?
It's a huge problem when you've got 3rd party bits in the mix. Those
3rd party bits typically come in binary form. If we do an ABI bump,
those 3rd party bits no longer work.
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.
If we can, that'd be great. I think it was mentioned earlier, but has
anyone looked at the abi tagging support that was added to gcc/binutils
to help with some of these issues in the libstdc++ 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.
I guess that's better than silently doing the wrong thing ;-) Still a
lousy position to be in.
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.
Right. You also want to fail to link when you can.
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.
It's certainly a pain point for Fedora/RHEL building. The bigger pain
point I see is for the end users who either have code that does the
wrong thing or no longer even runs.
Jeff