This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 status?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Allan McRae <allan at archlinux dot org>
- Cc: libc-alpha <libc-alpha at sourceware dot org>, <cltang at codesourcery dot com>
- Date: Fri, 31 Jan 2014 01:26:23 +0000
- Subject: Re: glibc 2.19 status?
- Authentication-results: sourceware.org; auth=none
- References: <52E649BF dot 5020400 at archlinux dot org>
My views on the current issues:
* Revert the TLS changes, including removing the bug number from the list
of fixed bugs and reopening the bug, and try again for 2.20. It's too
late to try any last-minute fixes to these changes.
* In the absence of consensus from the people building distributions with
the PPC64 LE port, change the symbol version to the logically correct
GLIBC_2.19, and get ABI test baselines checked in (even if the sysdeps
structure is ugly, which I think was the reason they weren't added
originally) to confirm the ABI in use. It's perfectly possible to build
from 2.17 or 2.18 sources with a GLIBC_2.19 symbol version; you might need
to backport the additions of new versions to Versions.def.
(I once configured a 2.5-based port with GLIBC_2.10 symbol versions in the
expectation that 2.10 was the version where that port would go upstream.
In the event, that port - nios2 - will hopefully be submitted for 2.20, of
course using GLIBC_2.20 symbol versions if so (the Linux kernel port has
moved to using the generic syscall ABI in the interests of upstream
acceptability, so there's a complete ABI break on that account as well).
All that went upstream at 2.10 time was a fix to allow the
version-handling scripts to work properly with versions greater than 2.9
<https://sourceware.org/ml/libc-alpha/2008-11/msg00015.html>.)
--
Joseph S. Myers
joseph@codesourcery.com