Distributions still suffering from s390 ABI change problems.

[Jeff Law]

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