This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, munroe at us dot ibm dot com, sjmunroe at us dot ibm dot com, libc-alpha at sourceware dot org, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Schwab <schwab at linux-m68k dot org>, Roland McGrath <roland at hack dot frob dot com>, Adam Conrad <adconrad at 0c3 dot net>
- Date: Fri, 31 Jan 2014 09:37:07 -0600
- Subject: Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- Authentication-results: sourceware.org; auth=none
- References: <1391008726 dot 16702 dot 105 dot camel at spokane1 dot rchland dot ibm dot com> <1391134218 dot 8757 dot 120 dot camel at oc8268013063 dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1401310215430 dot 12540 at digraph dot polyomino dot org dot uk> <52EB2860 dot 5010601 at redhat dot com>
- Reply-to: munroesj at us dot ibm dot com
On Thu, 2014-01-30 at 23:36 -0500, Carlos O'Donell wrote:
> On 01/30/2014 09:18 PM, Joseph S. Myers wrote:
> > On Thu, 30 Jan 2014, Steven Munroe wrote:
> >
> >> 3) Changing the default to 2.17 would also force a reset for everyone
> >> evolved in the PPC64LE ELf2 ABI today. It is also the most inclusive and
> >> in the long run provides a larger and more inviting ecosystem for the
> >> new platform. It still established definite boundary moving forward.
> >
> > I don't see it as more inclusive than using GLIBC_2.19, given that it's
> > easy to build a 2.17 or 2.18 glibc with GLIBC_2.19 symbol versions. (As
> > far as I can tell, no symbols got new versions for powerpc64 BE (at least)
> > because of a change of semantics in 2.18 or 2.19, so you don't need to
> > backport any changes of semantics to ensure binaries built against such a
> > 2.17 or 2.18 really are compatible with 2.19.)
>
> Adding 2.18 symbols to 2.17 creates a hybrid whose macros still
> present the release as 2.17. If I change the macros then it truly
> is a 2.18 release.
>
> I count at least 6 symbols versioned at GLIBC_2.18 that would need
> to be added to support a compatible 2.18 ABI:
> * __cxa_thread_atexit_impl
> * __issignaling
> * __issignalingf
> * __issignalingl
> * pthread_getattr_default_np
> * pthread_setattr_default_np
>
> This release behaves more like 2.17 than 2.18, but has a 2.18 ABI.
> I know of no major distribution that has shipped a hybrid like this.
> I don't know what other risks there might be with this solution...
>
> ... and that worries me.
>
> What I do know is that moving the ABI baseline to 2.17 will remove
> all of that risk for distributions based on 2.17.
>
Worries me too!
So this seems like a major issue, that makes "build a 2.17 or 2.18 glibc
with GLIBC_2.19 symbol versions" a high risk adventure.
It also seems that leaving the default at 2.18 has the same issue.
And moving the ABI default back to 2.17 is still the lowest risk for the
ecosystem.
Yes it will cause some extra work (rebuild) for most of us (this
includes IBMs internal development drivers), but the big issue seems to
be the full bootstrap. Which gives every one the yips.
Carlos has proposed one possible way to avoid the boot-strap and support
a automated rebuild. I have heard rumors of similar solutions from other
quarters.
So can we agree that option #3 is "just annoying" but "not the end of
the world as we know it".