> On our old CentOS 5 systems (packages frozen by Red Hat), I got a
> surprise message that has never appeared with any earlier version of
> emacs (I have almost 6000 logs for emacs builds going back as far as
> 20-Aug-1998):
>
>>> ...
>>> loading /local/build/cc/emacs-26.0.90/lisp/leim/leim-list.el (source)...
>>> Finding pointers to doc strings...
>>> Finding pointers to doc strings...done
>>> Dumping under the name emacs
>>> **************************************************
>>> Warning: Your system has a gap between BSS and the
>>> heap (258966655 bytes).  This usually means that exec-shield
>>> or something similar is in effect.  The dump may
>>> fail because of this.  See the section about
>>> exec-shield in etc/PROBLEMS for more information.
>>> **************************************************
>>> make[1]: *** [bootstrap-emacs] Segmentation fault (core dumped)
>>> ...
>
> I'm doubtful that CentOS 5 had any protection against stack/heap/bss
> collision, because such discussions have only shown up on security
> lists in the last several months.  Thus, it may be that the emacs test
> for the unexpected gap is faulty.

Hmm, a quick web search does seem to indicate that exec-shield only is
only set by default in CentOS 6 and up.  On the other hand, since you
got a segfault, the test for the gap is probably not faulty (just that
the warning text is imprecise: "exec-shield or something").

> The one class of operating systems for which emacs is known not to
> work out-of-the-box from standard GNU distribution channels is Alpine
> Linux. I have 5 VMs running various versions of that O/S.  Alpine uses
> muscl instead of glibc, and has a different memory model that breaks
> emacs, and also the tcsh shell.  Some Alpine versions have a patched
> emacs in the package system, but the latest ones do not.  Thus,
> emacs-26.0.90 will not build at all on Alpine Linux.

I was under the impression that Emacs 26 should be able to work with
muscl now, see Bug#22086[3] (which specifically mentions "Alpine
Linux").

[3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22086

> One final point: as far as I recall, in emacs-25 and earlier, the
> Makefiles were carefully written to be usable by traditional Unix
> make.  Sadly, that is no longer the case, and I think the changes that
> now mandate GNU make for building emacs should be rescinded.

I think this is unlikely to happen:

    The whole thing is a bit of a mess, and the mess is largely caused by
    Emacs using Automake, and Automake is needed only because of Gnulib
    (because Gnulib assumes Automake for portability to older systems
    lacking GNU Make). I'll look into fixing this so that Gnulib no longer
    assumes Automake, so that Emacs can stop relying on Automake. Since
    Emacs assumes GNU Make, it doesn't need Automake (except for the Gnulib
    code, which I think I can fix).

http://lists.gnu.org/archive/html/emacs-devel/2017-01/msg00097.html