Re: Removal of unexec support from glibc malloc
[Posted January 27, 2016 by jake]
From: |
| Paul Eggert <eggert-AT-cs.ucla.edu> |
To: |
| Florian Weimer <fweimer-AT-redhat.com> |
Subject: |
| Re: Removal of unexec support from glibc malloc |
Date: |
| Mon, 18 Jan 2016 11:24:16 -0800 |
Message-ID: |
| <569D3BE0.6050103@cs.ucla.edu> |
Cc: |
| Emacs Development <Emacs-devel-AT-gnu.org>, GNU C Library <libc-alpha-AT-sourceware.org> |
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?