[Emacs-diffs] emacs-25 32827b3: Default REL_ALLOC to 'no'

[Paul Eggert]

branch: emacs-25
commit 32827b374da7b085fc8a45bd35bf57a1afa325f9
Author: Paul Eggert <address@hidden>
Commit: Paul Eggert <address@hidden>

    Default REL_ALLOC to 'no'
    
    This should make ralloc-related bugs less likely on GNU/Linux
    systems with bleeding-edge glibc.  See the email thread containing:
    http://lists.gnu.org/archive/html/emacs-devel/2016-10/msg00801.html
    Do not merge to master.
    * configure.ac (REL_ALLOC): Default to 'no' on all platforms, not
    merely on platforms with Doug Lea malloc.  Although bleeding-edge
    glibc no longer exports __malloc_initialize_hook and so longer
    passes the configure-time test for Doug Lea malloc, ralloc tickles
    longstanding bugs like Bug#24358 and Bug#24764 and Emacs is likely
    to be more reliable without it.  This patch is not needed on
    master, which uses hybrid malloc in this situation.
---
 configure.ac |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index ae7dfe5..19b44bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2189,18 +2189,10 @@ if test "$doug_lea_malloc" = "yes" ; then
   AC_DEFINE(DOUG_LEA_MALLOC, 1,
     [Define to 1 if the system memory allocator is Doug Lea style,
      with malloc hooks and malloc_set_state.])
-
-  ## Use mmap directly for allocating larger buffers.
-  ## FIXME this comes from src/s/{gnu,gnu-linux}.h:
-  ## #ifdef DOUG_LEA_MALLOC; #undef REL_ALLOC; #endif
-  ## Does the AC_FUNC_MMAP test below make this check unnecessary?
-  case "$opsys" in
-    mingw32|gnu*) REL_ALLOC=no ;;
-  esac
 fi
 
 if test x"${REL_ALLOC}" = x; then
-  REL_ALLOC=${GNU_MALLOC}
+  REL_ALLOC=no
 fi
 
 use_mmap_for_buffers=no