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: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 15 Nov 2013 11:07:08 -0200
- Subject: Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311131535530 dot 24404 at digraph dot polyomino dot org dot uk> <201311131832 dot rADIWWl1006890 at d06av02 dot portsmouth dot uk dot ibm dot com> <20131114030709 dot GJ20756 at bubble dot grove dot modra dot org> <mvmbo1npe6q dot fsf at hawking dot suse dot de> <20131114224434 dot GA22514 at bubble dot grove dot modra dot org>
On 14-11-2013 20:44, Alan Modra wrote:
> On Thu, Nov 14, 2013 at 09:42:21AM +0100, Andreas Schwab wrote:
>> Alan Modra <amodra@gmail.com> writes:
>>
>>> We are very likely going to have a distro release off the 2.18 branch,
>>> or at least based on source prior to the FSF 2.19 release. Correct me
>>> if I'm wrong here, but I believe that distro glibc ought to be marked
>>> as 2.18.
>> That would have an incompatible ABI, so it won't happen.
> I don't understand this reply. We intend to take the glibc 2.18 release
> sources and apply a bunch of patches to add powerpc64le ELFv2 support.
>
> This is going to happen. Whether you like it or not. We can't wait
> for 2.19.
>
> The resulting libc clearly isn't FSF glibc-2.18 but you can't be
> saying that our libc is incompatible with FSF glibc-2.18 because
> there is no powerpc64le FSF glibc to be incompatible with! I'm left
> thinking you are issuing an edict from on high that the glibc 2.19
> release will have this line in shlib-versions:
>
> powerpc.*le-.*-linux.* DEFAULT GLIBC_2.19
>
> In other words, the earliest symbol set supported by the official
> powerpc64le glibc-2.19 will be GLIBC_2.19. That would indeed result
> in an incompatible ABI, and make it impossible for anyone using our
> libc to upgrade to the official glibc-2.19 when that comes out.
>
> But the *only* reason for an incompatible ABI would be this single
> line (and the corresponding line in nptl/shlib-versions)! What
> technical reason do you have for not allowing that the earliest
> symbol set might be set by something other than FSF glibc releases?
>
> Or what am I missing here?
Although I'm not very fond of using 2.18 as base for LE, as Alan pointed out
we have time constraints issues and we can't wait 2.19 to finish. The best
course of action in my opinion now is to provide a way to a developer grab
a 2.18 release and build a LE enabled GLIBC without to resorting in obscures
ways or manual backports.
For that we have some options and I'm not sure which is the best one. We can either:
1. Provide a new 2.18.1 release with the LE backports with or without the ELFv2
ABI.
2. Provide an official git branch, ibm-2.18-le for instance, based with 2.18
with LE patches.