This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.24 -- Release blockers


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]