This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 status?
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Allan McRae <allan at archlinux dot org>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 4 Feb 2014 16:18:15 -0800 (PST)
- 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> <Pine dot LNX dot 4 dot 64 dot 1402050004130 dot 25166 at digraph dot polyomino dot org dot uk>
> 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.
Agreed.
> 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.
Broadly agreed with some of the details to be argued later.