This is the mail archive of the libc-alpha@sourceware.org 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] change GLIBC PPC64/ELF2 ABI default to 2.17


On 01/29/2014 02:39 PM, Adam Conrad wrote:
> On Wed, Jan 29, 2014 at 12:00:47PM -0700, Jeff Law wrote:
>>
>> Either way, this situation is going to be painful.  But I believe
>> resetting the symbols to a 2.17 base will ultimately make the
>> ppc64-le port more accessable to a wider developer audience.
> 
> I believe that RedHat versioning their symbols to match what's
> currently upstream would ultimately make ppc64le more accessible
> to a wider developer audience.  I can make contentless statements
> too.

The argument remains that using a 2.17 baseline will more easily
support any distributions already using 2.17. It will not force
them to use 2.18, nor do any kind of hybrid backport of 2.18
symbols into 2.17. These risks become zero when we use 2.17 as the
baseline.
 
> There are two obvious solutions to your problem (re-version your
> symbols, or use a newer glibc), it's not as if keeping the version
> upstream unchanged makes either of those impossible, it just avoids
> shafting others for you not having been involved in the public
> discussion on this matter months ago.

That has risks that simply turning the crank on a rebuild doesn't.
The hack also has no benefit, while turning the crank probably
fixes bugs you didn't know you had (with a gcc update first
obviously).

> Ultimately, this isn't about accessiblity, it's about who wants to
> do work, and who should be penalised for having done work earlier
> on the promise of a stable ABI.

That's exactly the definition of accessibility! Making it easy
for others to join the ppc64le ecosystem by reducing the amount
of work required.
 
> Can we just drag our collective feet on this patch that's been
> proposed days before the final freeze and stop pretending that we
> can argue that "the ABI is known-malleable until a release is cut"
> is equivalent to "we should change the established ABI to suit the
> squeakiest wheel because we can"?

Squeek.

Cheers,
Carlos.


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