This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Emacs Development <Emacs-devel at gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 18 Jan 2016 11:24:16 -0800
- Subject: Re: Removal of unexec support from glibc malloc
- Authentication-results: sourceware.org; auth=none
- References: <569CDB81 dot 6040600 at redhat dot com>
Florian Weimer wrote:
this is a heads-up that glibc malloc will likely remove support code for
the Emacs unexec mechanism during the coming year.
Thanks for that heads-up. Making the Emacs unexec mechanism more portable has
been our to-do list for some time, and this will light more of a fire under it.
We're already under a feature freeze for Emacs 25, though, so Emacs 25 will have
to go out without the fix (which will be reasonably substantial, alas).
This only affects the glibc API, so Emacs is unlikely to compile from
source until you remove the undump mechanism.
Emacs should still build and run even if the glibc API is changed, as Emacs
./configure probes for the glibc malloc-related API and falls back on its own
malloc implementation otherwise. If some glitch prevents this from working with
the new glibc API, I'd like to get this fixed before Emacs 25 comes out, so that
Emacs 25 will build and run with newer glibc.
Can you explain the problem in more detail? What are the symptoms if you do the
following with the next-generation glibc API?
git clone --branch emacs-25 git://git.savannah.gnu.org/emacs.git
cd emacs
./autogen.sh
./configure
make
Is there some way that Emacs developers (who are typically not glibc experts)
can easily test with the next-generation glibc API?