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: Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>
- Date: Wed, 5 Feb 2014 00:12:11 +0000
- Subject: Re: glibc 2.19 status?
- Authentication-results: sourceware.org; auth=none
- References: <52E649BF dot 5020400 at archlinux dot org> <20140128205657 dot 16DBA74438 at topped-with-meat dot com> <52E9DEB7 dot 4000709 at redhat dot com> <52E9E84F dot 50907 at redhat dot com> <52EA682D dot 90900 at archlinux dot org> <52F03BEC dot 1020202 at archlinux dot org> <52F062C5 dot 6050705 at redhat dot com> <52F06713 dot 1040005 at archlinux dot org>
On Tue, 4 Feb 2014, Allan McRae wrote:
> Joseph suggests reverting them[1] and Roland agreed[2]. Here is more
> from Roland about the issue and concerns about breaking the ABI [3].
>
> [1] https://sourceware.org/ml/libc-alpha/2014-01/msg00720.html
> [2] https://sourceware.org/ml/libc-alpha/2014-01/msg00770.html
> [3] https://sourceware.org/ml/libc-alpha/2014-01/msg00719.html
>
> As far as I see, there was no formal conclusion on what to do for
> glibc-2.19 here. Hence the query in the status list.
Well, what we should not do is sit around indefinitely delaying the
release! Revert the changes, run the testsuite on x86_64 and x86, commit
the reversion and start the process for the actual release. It's clear we
do not have consensus to keep the changes in 2.19, which is what matters.
We can discuss later in what form such changes might come back for 2.20
(on the whole my view is that the problems are fundamental to the approach
of signal-safe allocation and would best be avoided by the approach of
allocating at dlopen / pthread_create time - where objects opened with the
old symbol version of dlopen, or using a new RTLD_LAZY_TLS flag, keep lazy
TLS but do without signal-safety). I think providing better interfaces
for tools to identify memory allocated by glibc is a good idea, but
largely orthogonal to solving the TLS signal-safety problem.
--
Joseph S. Myers
joseph@codesourcery.com