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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: <munroe at us dot ibm dot com>, <sjmunroe at us dot ibm dot com>, <libc-alpha at sourceware dot org>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Schwab <schwab at linux-m68k dot org>, Roland McGrath <roland at hack dot frob dot com>, Adam Conrad <adconrad at 0c3 dot net>
- Date: Fri, 31 Jan 2014 17:17:48 +0000
- Subject: Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- Authentication-results: sourceware.org; auth=none
- References: <1391008726 dot 16702 dot 105 dot camel at spokane1 dot rchland dot ibm dot com> <1391134218 dot 8757 dot 120 dot camel at oc8268013063 dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1401310215430 dot 12540 at digraph dot polyomino dot org dot uk> <52EB2860 dot 5010601 at redhat dot com>
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.
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.
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.
--
Joseph S. Myers
joseph@codesourcery.com