This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus summary around changing GLIBC PPC64 LE ABI default to 2.17
- From: Allan McRae <allan at archlinux dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Adam Conrad <adconrad at 0c3 dot net>, Andreas Jaeger <aj at suse dot com>, Steven Munroe <sjmunroe at us dot ibm dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jeff Law <law at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, Andreas Schwab <schwab at suse dot de>, Brooks Moses <bmoses at google dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 01 Feb 2014 11:55:30 +1000
- Subject: Re: Consensus summary around changing GLIBC PPC64 LE ABI default to 2.17
- Authentication-results: sourceware.org; auth=none
- References: <52EC34E1 dot 7040008 at redhat dot com> <52EC3861 dot 7010503 at redhat dot com> <CAMe9rOpKLzTXADGiUEqfaAPU44=USKpouaWC2ReU_hzoU+FFqg at mail dot gmail dot com> <52EC4E3A dot 4080908 at redhat dot com>
On 01/02/14 11:30, Carlos O'Donell wrote:
> On 01/31/2014 07:08 PM, H.J. Lu wrote:
>>> (c) Move the ABI baseline to GLIBC_2.17.
>>>
>>> - This is what Red Hat and IBM propose to support 2.17-based and newer
>>> distributions in the PPC64 LE ecosystem.
>>>
>>
>> Is this considered as the new policy or an exception?
>
> I view this as an exception that is a direct result of this and other
> discussions.
>
> New ports should always aim to follow (a). It avoids all of us spending
> Fridays talking about the benefits and merits of rebuilds versus symbol
> porting and the risks therein.
>
Is it really going to be an exception? What will happen when the next
architecture is made that enterprise distros want to support? Will the
ABI baseline be set to the next glibc release version, or will it need
set to a value determined by what glibcs are being run by interested
distros? And what if a distro misses the initial discussion and it
turns out they need an older version of glibc to be supported.
The argument "no major enterprise distribution has been released with a
glibc patched like this" for moving the baseline ABI to common ground
will always apply. And this will set the precedent, whether we call it
an exception or not.
For what it is worth, having spent my Saturday morning reading through
every message about this, I see no way to do what I see is best for
glibc (set ABI at 2.19), what is best for some distros (leave it at
2.18) and best for other distros (change to 2.17). Any course of action
is going to leave people unhappy. But changing to 2.17 is probably best
for the uptake of the architecture, so I can see why the machine
maintainer would select that. And in the long run it means the
architecture will be better supported in glibc, so that decision is not
that bad for glibc either.
Allan