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 01/30/2014 09:18 PM, Joseph S. Myers wrote:
> On Thu, 30 Jan 2014, Steven Munroe wrote:
> 
>> 3) Changing the default to 2.17 would also force a reset for everyone
>> evolved in the PPC64LE ELf2 ABI today. It is also the most inclusive and
>> in the long run provides a larger and more inviting ecosystem for the
>> new platform. It still established definite boundary moving forward.
> 
> I don't see it as more inclusive than using GLIBC_2.19, given that it's 
> easy to build a 2.17 or 2.18 glibc with GLIBC_2.19 symbol versions.  (As 
> far as I can tell, no symbols got new versions for powerpc64 BE (at least) 
> because of a change of semantics in 2.18 or 2.19, so you don't need to 
> backport any changes of semantics to ensure binaries built against such a 
> 2.17 or 2.18 really are compatible with 2.19.)

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.

Cheers,
Carlos.


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