glibc 2.24 -- Release blockers

[Paul Eggert]

On 07/15/2016 10:35 AM, Florian Weimer wrote:
>> I expect such an approach is too much to expect to fold into Emacs 25,
>> which is close to release. We could try something along those lines for
>> the next major Emacs release, but that won't be for a while.
>
> In this case, I suggest *not* to revert the __malloc_initialize_hook 
> removal because if we put it back in, Emacs will not use its internal 
> malloc, and we get no additional test coverage compared to we had 
> before the removal.

By "test coverage" do you mean some testing by a buildbot that builds 
and runs Emacs with bleeding-edge glibc? If so, we shouldn't need to 
remove __malloc_initialize_hook to test this; all that should be needed 
is './configure emacs_cv_var_doug_lea_malloc=no', which causes Emacs 
'configure' to pretend that __malloc_initialize_hook does not exist.

How about the following more-conservative approach instead?

1. Restore __malloc_initialize_hook in glibc.

2. Try to get Emacs 25 to work even when configured with './configure 
emacs_cv_var_doug_lea_malloc=no'. I'm hoping that something like the 
patch I proposed in 
<https://sourceware.org/ml/libc-alpha/2016-07/msg00458.html> is enough 
to do this, and will be accepted by the Emacs maintainers this close to 
a release.

3. If (2) is too ambitious for Emacs 25, get it to work with Emacs 26. 
This should be quite doable, as essentially the same thing is already 
working with Cygwin.

4. Once a stable version of Emacs is published with either (2) or (3), 
then remove __malloc_initialize_hook from glibc.