Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

On 15-11-2013 16:20, Adhemerval Zanella wrote:
> 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 <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.
>>
> 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.

Hi all,

Now that all but this PowerPC64 LE patch has been approved, I would like to close this matter.
Joseph, you raised two concerns with current patch:

1. Add configure tests to ensure only BE + ELFv2 and LE + ELFv2.
2. Setting the minimum symbol version in this case for GLIBC_2.19

Regarding 1. LE do runs with ELFv1 ABI, although it won't be the focus. I'm thing about keep
Uli check with hacker mode enabled and a more one to emit a warning message (AC_MSG_WARN)
when building LE + ELFv1 without hacker mode.

Regarding 2. I have create the vendor branch ibm/2.18-new/master. It is based on 2.18 with
some bugfixes and powerpc specific backports plus all the LE enablement patches. It is suffice
to create a full ELFv1 and ELFv2 enabled GLIBC for PowerPC64 LE.

I am aware you and Andreas suggests against it, but as Alan and Uli stated this will happens
anyway and I think it is wise to avoid more future incompatibilities to GLIBC have a way (even
by a vendor branch) to support it. I am not sure if we should release a 2.18.1 with such support,
although I will do so if is required.

Binutils and gcc already supports this new version and kernel support has started to build
itself with ELFv2. I really like to close this matter so we can move forward.