This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Distributions still suffering from s390 ABI change problems.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]