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.


On 07/14/2014 04:24 PM, David Miller wrote:
> From: "Carlos O'Donell" <carlos@redhat.com>
> Date: Mon, 14 Jul 2014 16:15:26 -0400
> 
>> I've never seen a clean way to do a structure size increase, so in practice
>> that's always a SO version bump. I also don't know what kind of breakage
>> you have in the entire tooling when you do that. I expect some.
>  ...
>> We've already had an entire release out with this change. There are binaries
>> with libc.so.6 already in the wild with the new ABI. So it seems like a mess
>> any way we swing it.
> 
> We've told users we will maintain strict compatability against a given
> SO version of glibc.

Yes we have.
 
> Now, s390 users cannot give eachother binaries neither backwards nor
> forwards because of this change.  It breaks in _both_ directions.

Yes, that's true.

So what do we do about it?

I want IBM to be a part of this discussion, but we may have to wait
for another day to let Andreas Krebbel comment.

> I have two theories as to why we didn't do any SO bumps in the past,
> it's either 1) we found alternative ways to solve the problem (symbol
> versioning, etc.) or 2) the maintainer in the past was strongly
> against SO version bumps and nobody felt strong enough to fight him on
> this point.

You know, that's entirely it. That weird apprehension I feel is most
certainly (2). I don't believe (1) can actually solve the mixed-ABI
use cases that trigger the problems. If we had more attribute sections
for each ABI change and made sure they matched up we could prevent
such images from being loaded by the dynamic loader, but that isn't
much of a solution.

I've never slouched from doing work. I see no serious technical reasons
for not bumping the soname other than breaking tooling that explicitly
always looks for libc.so.6. It would do us well to fixup such tooling
to actually look at the binary to see what libc it's using by examining
DT_NEEDED.

I'm happy to push a new world order where we actually stick to our guns
and follow what should be best practice.

Should we bump the soname for glibc on s390?
 
Cheers,
Carlos.


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