Re: Handling s390 libc ABI change in Debian
On Tue, Jul 15, 2014 at 03:49:04AM -0400, Carlos O'Donell wrote:
> On Tue, Jul 15, 2014 at 1:18 AM, Aurelien Jarno <aurel32@debian.org> wrote:
> > On Mon, Jul 14, 2014 at 11:14:42PM -0400, Carlos O'Donell wrote:
> >> On Mon, Jul 14, 2014 at 4:36 PM, Aurelien Jarno <aurel32@debian.org> wrote:
> >> > glibc 2.19 has changed the libc ABI on s390, more specifically the
> >> > setjmp/longjmp functions [1] [2]. Symbol versioning is used to handle
> >> > some cases, but it doesn't work when a jmp_buf variable is embedded
> >> > into a structure, as it changes the size of the structure. The result
> >> > is that mixing programs or libraries built with 2.18 with ones built
> >> > with 2.19 do not work anymore, usually they end up with a segmentation
> >> > fault. Some persons from this list have experienced that with perl.
> >>
> >> That is not true. This is an over generalization of the problem. You
> >> can use libraries built with 2.18 and 2.19 and they work just fine.
> >
> > I agree I probably a bit over exaggerated here, but the problem is real,
> > breakages do happen, and some persons on this mailing list have already
> > experienced them.
> >
> >> The extent of the problem in correct language is listed here:
> >> https://sourceware.org/glibc/wiki/Release/2.19#Packaging_Changes
> >
> > This seems to minimize the problem, listing only perl. In practice we
> > have seen much more breakages, part of them being due to the change of
> > the __pthread_unwind_buf_t struct.
>
> That is a change that nobody reported. You're the first to mention it
> and that does make it more serious. We have discussed this upstream
> and I agree that we need more versioning of the interfaces there to
> support the change fully.
>
> >> > We first thought it was limited to a few packages (even if all perl is
> >> > already more than that), but as time goes more and more issues are
> >> > found. libpng and gauche are also affected, the issue with mono is
> >> > also likely due to this ABI change.
> >>
> >> That is new information, and it is important for distributions to
> >> relay this information back upstream where the decision for a SO bump
> >> can be made.
> >
> > I can follow up with a list affected packages, but we are slowly
> > discovering them one by one, so it might takes time. So far we have:
> >
> > * Mixing modules/libraries built with pre-2.19 and 2.19 libc
> > - perl
> > - libpng
>
> You can never support a mixed-ABI environment with versioning.
>
> You must update all of those packages at once.
>
> The best we could do is warn the user of the incompatibility at
> runtime and refuse to load the module via dlopen, or refuse to start
> the application at startup.
For perl we handled that using dependencies in the package manager, and
we can probably add some more checks for user modules. That said that do
not scale if we discover more and more affected packages. This is my
fear so far.
> > * Using libc 2.19 without rebuilding anything:
> > - gauche
> > - mono
>
> This we believe to be pthread issues.
Yes, this is the pthread issue.
> > It's a huge work for Debian, maybe not for other distribution, as it
> > basically means we have to rebootstrap everything. This includes manual
> > bootstrapping of self-dependent languages (haskell, gnat, ...) and
> > manual handling of some dependencies loop. In addition it's something
> > which hasn't been done since the libc5 transition, so we might discover
> > some unexpected issues.
>
> Why do you have to do that? Is it just like for rpm where the
> packaging system encodes the SONAME as a dependency? We would also
> need a manual bootstrap in Fedora because of this issue.
I assumed that both libc can't be used simultaneously, so that's
basically like bootstrapping a new architecture, except the manual
bootstrapping of self-dependent languages can be done more easily.
Cheers,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: