glibc 2.19 status?

[Roland McGrath]

> 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.