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: Adam Conrad <adconrad at 0c3 dot net>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Thu, 14 Nov 2013 14:43:16 -0700
- 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> <Pine dot LNX dot 4 dot 64 dot 1311141610100 dot 26499 at digraph dot polyomino dot org dot uk>
On Thu, Nov 14, 2013 at 04:14:57PM +0000, Joseph S. Myers wrote:
>
> 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.
For backporting individual symbols, this makes sense. For a whole new
port, I'm not sure it does as much. Either way, 2.18 is what's has
been committed, so I don't see much point in changing it now just to
align with the first FSF release. If that ends up being the decision
taken, though, we'd all need to know sooner rather than later, as it
means rebuilding the world for the artificial ABI break.
... Adam