__malloc_initialize_hook removal in glibc 2.24

[Florian Weimer]

I would like to obtain an explicit decision about the removal of 
__malloc_initialize_hook in glibc 2.24.

The situation is roughly this: __malloc_initialize_hook was deprecated 
in 2011.  Emacs keeps using it to this day, ignoring the deprecation 
(and despite multiple warnings on emacs-devel that the interface is 
going away).  As a result, the fallback code in Emacs in src/gmalloc.c 
has not seen much test coverage on GNU/Linux systems.  Testing in 
OpenSUSE and Fedora uncovered an issue on ppc64/ppc64le.  Other 
platforms may have problems as well.

We have a chicken-and-egg issue here.  Until Emacs starts using 
src/gmalloc.c on GNU/Linux (or gets rid of the non-portable dumper, but 
this is going to be a far more radical change), src/gmalloc.c will not 
see much test coverage (particularly on GNU/Linux).  Less coverage means 
that bugs remain, and glibc cannot remove __malloc_initialize_hook (or 
take other measures to disable heap dumping support) because that would 
break Emacs for too many users (well, those users who compile their own 
Emacs binaries and are on bleeding-edge glibc versions, which can't be 
that many).

I discussed the matter with Carlos and our Emacs maintainer, and we can 
implement the API removal in the upcoming Fedora 25 release (which uses 
glibc 2.24 and Emacs 25), even if glibc 2.24 upstream releases with 
__malloc_initialize_hook.  Fedora 25 should see sufficiently wide use 
across architectures to iron out any gmalloc wrinkles.  This means that 
we can reconsider upstream removal for glibc 2.25 (and I really wish to 
avoid delaying removal further).

Considering the above, we could revert the __malloc_initialize_hook 
removal for the glibc 2.24 release if that is what people what.  My 
objections to the revert are mainly philosophical in nature (it's 
essentially rewarding a reckless disregard for deprecation notices) and 
less technical (because it seems we can get the required gmalloc testing 
after all).

Thanks,
Florian