This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17


On Fri, Jan 31, 2014 at 1:10 PM, Andreas Jaeger <aj@suse.com> wrote:
> On 01/31/2014 03:10 AM, Steven Munroe wrote:
>> On Wed, 2014-01-29 at 09:18 -0600, Steven Munroe wrote:
>>> Starting a new platform is always more complicated then we would like
>>> and we often find examples where the needs of the larger Linux community
>>> trumps our initial assumptions.
>>>
>>> Each distribution decides how it will support a new platform and we have
>>> requests to allow for back-ports of PPC64LE ELF2 to a GLIBC-2.17.
>>>
>>> To support the larger Linux community we need to insure forward
>>> compatibility across releases, and this implies setting the GLIBC
>>> powerpc.*le-.*-linux.* default back 2.17.
>>>
>>> We are not asking to apply this patch retroactively to the GLIBC-2.17
>>> source. But we like to get this patch accepted upstream to serve notice
>>> to all involved (in PPC64LE) that GLIBC-2.17 is the oldest symbol set,
>>> and promise this it final word on the topic.
>>>
>>> We also ask that all distributions apply this patch and ELF2 ABI patches
>>> if they planing to support the PPC64LE platform and doing a back port of
>>> the to GLIBC-2.17 or 2.18.
>>>
>>
>> So we have had a spirited debate and expressed our issues in a
>> forthright manner. Clearly this is frustrating to many of you but I also
>> see a developing consensus.
>>
>>       * GLIBC-2.19 is the first official release for the new PPC64LE
>>         ELF2 ABI.
>>       * GLIBC-2.19 establishes the basis for compatibility for the ABI.
>>       * GLIBC-2.19 will establish the "default or minimum" version for
>>         this ABI.
>>       * Once GLIBC-2.19 is released the "default" version should not
>>         change (ever!).
>>       * Any back-ports of this ABI to older versions of GLIBC are
>>         responsible to maintaining forward compatibility to 2.19.
>>       * No back-ports will be supported earlier then "default" set in
>>         the official GLIBC-2.19 release.
>>
>> Does anyone disagree with the statements above?
>>
>> Currently (upstream) the "default" version is set to 2.18. We have a
>> request to move than back to 2.17. Other have expressed the opinion that
>> the ABI should no exist before 2.19.
>>
>> In reality there is a lot of parallel development based on early
>> versions of this ABI across many (hundreds) developers (community and
>> corporate). We can not stop this and we never want to. But we do need to
>> bring order to what is now a somewhat chaotic situation.
>>
>> Anyone involved in early development of a new platform and ABI is
>> exposed to one or more resets. Reasons include changing to the final
>> GLIBC ABI and version enforcement or nasty pervasive compiler bugs,
>> among others.
>>
>> Jeff and Carlos are looking at means to reduce the reset from a "full
>> bootstrap and rebuild the world" to just a "automated rebuilt the
>> world". All of us in active development are concerned about this and I
>> hope they will share their solution.
>>
>> Now I would to explore the implications of the most contentious issue:
>>
>> 1) Changing the default to 2.19 would force a reset for everyone evolved
>> in the PPC64LE ELf2 ABI today. It would also exclude (for some long
>> period of time) some of the current distributors.
>
> And this is how it was handled in the past - both x86-64 and x32 had to
> change their default when they were committed in glibc.
>

I have done both rebuild and backport for x32.  I rebuilt x32 binaries
after x32 went into glibc 2.16.  I backported x32 support to glibc 2.15
with symbol version to set GLIBC_2.16.   I don't consider it particularly
hard and don't understand why it is such a big deal.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]