Re: Distributions still suffering from s390 ABI change problems.

[Aurelien Jarno <aurelien at aurel32 dot net>]

On Tue, Jul 15, 2014 at 01:51:10AM -0400, 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? 
> 
> 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.

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.

> 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.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net