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: "Carlos O'Donell" <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, 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>, "Joseph S. Myers" <joseph at codesourcery dot com>, munroe at us dot ibm dot com
- Date: Fri, 31 Jan 2014 17:17:09 -0500
- 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> <CAMe9rOrZ3K+qYjPsMmANucGmiLivQQ5OVDhLdVZDNV0mgLgJiA at mail dot gmail dot com> <52EC2041 dot 7070906 at redhat dot com>
On 01/31/2014 05:14 PM, Carlos O'Donell wrote:
> On 01/31/2014 04:46 PM, H.J. Lu wrote:
>> 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.
>
> It can.
>
> It's just software it can do anything.
>
> However I've never seen it done by an distro before, and while
> technically possible it's something I'd like to avoid to reduce
> risk.
>
> We all know how to rebuild packages and it's easy and we know
> there are no problems there.
... and when I say easy I do not mean it's quick, but that the
process is a known function.
Cheers,
Carlos.