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: Jeff Law <law at redhat dot com>
- To: Adam Conrad <adconrad at 0c3 dot net>, "Carlos O'Donell" <carlos at redhat dot com>
- Cc: munroesj at us dot ibm dot com, libc-alpha at sourceware dot org, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Wed, 29 Jan 2014 12:00:47 -0700
- 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> <52E92E7C dot 1040707 at redhat dot com> <20140129172158 dot GT15976 at 0c3 dot net>
On 01/29/14 10:21, Adam Conrad wrote:
As such a distribution that has thousands of publicly available
binaries built against that ABI, I object quite strongly to this.
But using an unreleased upstream version of glibc, right? ISTM until
upstream releases a version all bets are effectively off.
Also, it would also seem to me that with the ongoing changes in GCC that
are fixing bootstrap bugs on ppc64-le that a mass rebuild at some point
in the relatively near future would be very wise.
I understand the reasons for this, and that for the disribution that
is based on 2.17, it would mean they need to version their symbols
at 2.18 and backport the missing symbols, but I'm not sure that's a
valid reason to force other distributions to rebootstrap and rebuild
the world.
But is forcing one distribution to do backporting because another has
binaries in the wild using an unreleased version glibc valid either?
Either way, this situation is going to be painful. But I believe
resetting the symbols to a 2.17 base will ultimately make the ppc64-le
port more accessable to a wider developer audience.
When this came up on the list in November, the "people are already
using these symbol versions" argument was why the "it needs to change
to 2.19" argument fell flat, and it stayed at 2.18. I'm not sure how
the groups who didn't want to break ABI were relevant then, but have
become irrelevant months later.
Sorry, didn't catch that discussion :(
This double-double transition rumour is something it would be nice to
nail down as well, especially if it's something we can sort earlier
than later, but it's also not as world-ending an ABI break as changing
the baseline symbol version.
Well, it's an ABI break, but with a little engineering binaries of the
two types can co-exist with multilibs and such.
jeff