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

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/31/2014 12:17 PM, Joseph S. Myers wrote:
> On Thu, 30 Jan 2014, Carlos O'Donell wrote:
> 
>> Adding 2.18 symbols to 2.17 creates a hybrid whose macros still
>> present the release as 2.17. If I change the macros then it truly
>> is a 2.18 release.
>>
>> I count at least 6 symbols versioned at GLIBC_2.18 that would need
>> to be added to support a compatible 2.18 ABI:
>> * __cxa_thread_atexit_impl
>> * __issignaling
>> * __issignalingf
>> * __issignalingl
>> * pthread_getattr_default_np
>> * pthread_setattr_default_np
>>
>> This release behaves more like 2.17 than 2.18, but has a 2.18 ABI.
>> I know of no major distribution that has shipped a hybrid like this.
>> I don't know what other risks there might be with this solution...
>>
>> ... and that worries me.
>>
>> What I do know is that moving the ABI baseline to 2.17 will remove
>> all of that risk for distributions based on 2.17.
> 
> I think the risk is the same whatever version you pick, if you don't 
> backport new symbols but just set the versions of symbols already in 2.17 
> to whatever version they end up having in 2.19.

How can the risk be the same?

Assuming a 2.17-based release:

If you use GLIBC_2.17 as the base ABI then you need only backport those
required critical PPC64 LE patches. There are no ABI implications.

If you use GLIBC_2.18 you not only need to backport those required
critical patches, but also anything else to make the ABI complete,
followed by anything else that might have caused subtle behavioural
differences that you don't know about yet (which need not be considered
bugs).

The farther forward the ABI baseline the more work it is to backport
and maintain the features. This is exactly why distributions rebase
to newer software versions. Yet we can't ignore the immediate needs 
of the ecosystem for older stable software components.

Despite Roland's comments about future users being important, there
is no future if we don't enable a large enough ecosystem around
the hardware. That would certainly be bad for all users.

> In any case, the ABI for each (symbol, version) pair that you need to be 
> compatible with is the ABI for that pair in 2.19 release.  Whether the 
> version is called GLIBC_2.19 (to reflect the release that is definitive 
> for the semantics of that pair), GLIBC_2.18 or GLIBC_2.17 makes no 
> difference to the requirement that you ensure the semantics for that pair 
> in your 2.17-based version are the same as in 2.19.

Sure, in general, but it's *fewer* symbols to backport and thus less risk.

It's also something no one has ever done in a production release.

I don't want to be the first person to try this.

I guarantee you there will be problems.

Therefore the easiest and least risk option for supporting 2.17-based
distributions is to move the ABI baseline to 2.17.
 
> It's true that if the versions are GLIBC_2.18 or GLIBC_2.19 then the set 
> of symbols with that version in your 2.17-based version is a strict subset 
> of the set of symbols with that version in 2.19, but that doesn't break 
> anything.

No, but it makes it less risk to support.

Cheers,
Carlos.