This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Adam Conrad <adconrad at 0c3 dot net>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 14 Nov 2013 16:14:57 +0000
- Subject: Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number
- Authentication-results: sourceware.org; auth=none
- References: <201311131517 dot rADFHZvf003435 at d06av02 dot portsmouth dot uk dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1311131535530 dot 24404 at digraph dot polyomino dot org dot uk> <20131114155705 dot GU16259 at 0c3 dot net>
On Thu, 14 Nov 2013, Adam Conrad wrote:
> On Wed, Nov 13, 2013 at 03:38:00PM +0000, Joseph S. Myers wrote:
> >
> > The version there is wrong - it should be GLIBC_2.19, not GLIBC_2.18,
> > since the 2.18 release did not in fact support little-endian. But apart
> > from that, just the configure checks.
>
> There's intent to release likely more than one distribution based on
> glibc 2.18 and backported powerpc64le patches from 2.19/trunk. If
> we version @2.18 and upstream versions @2.19, we either force a nasty
> ABI horizon we need to fix, or we need to carry a version patch for,
> well, ever, and be gratuitously incompatible with upstream. Neither
> of those is appealing.
You can also use GLIBC_2.19 versions in your backport based on 2.18. You
may lose some compatibility checking for binaries using any symbols that
are actually new in 2.19 and not in your backport, or get incompatibility
if a symbol changes incompatibly between 2.18 and 2.19 (but so far only
hppa has a new symbol at version 2.19), but that's generically the best
thing to do in cases where a distributor wants to backport an individual
new symbol, for example - have that symbol at its upstream version.
--
Joseph S. Myers
joseph@codesourcery.com