bug#23760: 25.0.95; emacs 25.0.95 doesn't build with glibc-2.23.90

[Florian Weimer <fweimer@redhat.com>]

On 06/19/2016 05:02 AM, Paul Eggert wrote:
> If I understand things correctly, the Emacs 'configure' script
> discovered that the test glibc version did not declare and define a
> symbol __malloc_initialize_hook, and so Emacs supplied its own
> implementation of malloc, complete with __malloc_initialize_hook. Since
> __malloc_initialize_hook was poisoned, this didn't work.

Yes, that's right.  I didn't account for the possibility that Emacs 
would use symbols in the implementation namespace for implementing its 
own malloc.

> I suppose Emacs could work around the problem by using
> __malloc_initialize_hook when linked against an old glibc, and by using
> a new symbol emacs_malloc_initialize_hook when linked against its
> substitute implementation. Although this would insulate distant-future
> versions of Emacs against the poisoning, it wouldn't work for Emacs 25
> (the next Emacs version) and earlier; these systems would be unbuildable
> with a glibc that poisons __malloc_initialize_hook. So as a practical
> matter, aren't we better off having glibc simply not declare
> __malloc_initialize_hook?

You mean, not declare it in <malloc.h>?  I already posted a patch for that:

   <https://sourceware.org/ml/libc-alpha/2016-06/msg00500.html>

I'm more worried about the other __ variables in the Emacs malloc. 
Their in Emacs definition does not even match the one in glibc.  The 
difference is probably harmless, but it is fairly close to be being broken.

Thanks,
Florian