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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Brooks Moses <brooks dot moses at dpdx dot net>, GNU C Library <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, munroe at us dot ibm dot com
- Date: Fri, 31 Jan 2014 13:46:08 -0800
- Subject: Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- Authentication-results: sourceware.org; auth=none
- References: <20140131192403 dot GF99202 at jinx> <52EC17A5 dot 1090106 at redhat dot com>
On Fri, Jan 31, 2014 at 1:37 PM, Jeff Law <law@redhat.com> wrote:
> On 01/31/14 12:24, Brooks Moses wrote:
>>
>>
>> My assumption at this point is that there is _no_ such purely technical
>> argument. Carlos and Jeff have implied that RedHat's team is under
>> constraints that would prohibit doing so, and have implied that these
>> are for "management" reasons rather than "technical" reasons. As I have
>> no connection to their team, I am free to speculate on what those might
>> be; one that IMO carries reasonable weight is that breaking the "you
>> need a glibc 2.18 or later package to provide symbols of 2.18 or later"
>> invariant will confuse any users or support teams that run into a
>> problem with a 2.18-versioned symbol and are using their 2.17 library.
>>
>> It would, I think, be good for someone from RedHat to describe a bit
>> more what precisely what their constraints _are_ and what their
>> alternate option is if the patch isn't approved, even if they are not at
>> liberty to share the reasons for those constraints or in a position to
>> debate them.
>
> Unfortunately we are not at liberty to discuss the constraints or why they
> exist. I will say that many are pretty obvious, some less so. I realize
> our inability to discuss them in any detail makes the entire discussion
> tougher than it needs to be. Heavy sigh....
>
Let's assume that RedHat must use glibc 2.17 and can't move
it to glibc 2.18/2.19. What I don't understand is why GLIBC_2.19
can't be used as symbol version in glibc 2.17.
--
H.J.