This is the mail archive of the 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] PowerPC64 ELFv2 ABI 6/6: Bump soname version number

On 15-11-2013 11:07, Adhemerval Zanella wrote:
> On 14-11-2013 20:44, Alan Modra wrote:
>> On Thu, Nov 14, 2013 at 09:42:21AM +0100, Andreas Schwab wrote:
>>> Alan Modra <> 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.
I have created the branch ibm/2.18-new/master with all the LE patch pushed so far
with also the pending PPC64 ELFv2 patches. This tree is intended for testing and when
Alan and Urich gave me and ok I'll replace the ibm/2.18/master. I pushed all the
patches already in ibm/2.18/master inside this branch.

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