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.