bug#28882: [bug-gnu-emacs] emacs-26.0.90 build feedback

[Noam Postavsky]

"Nelson H. F. Beebe" <beebe@math.utah.edu> writes:

> Unfortunately, a further 77 automated builds were broken by this
> obnoxious failure:
>
>>> ...
>>>     configure: error: The following required libraries were not found:
>>>      gnutls
>>>     Maybe some development libraries/packages are missing?
>>>     If you don't want to link with them give
>>>      --with-gnutls=no
>>>     as options to configure
>>> ...
>
> My suspicion is that the gnutls package is needed only for editing
> files across a network, which few users ever do.  Thus, my strong view
> is that, while it is fine for configure to test for the availability
> of gnutls, it should NOT be a show-stopper that requires a manual
> override and a fresh build attempt with that extra option.

It's also used for downloading packages from repositories.  It is
optional there, but in recent times not using https for this is
considered unacceptable (e.g. [1]).  You might call this mass hysteria,
or you might call it sanity being restored, but either way, I don't
think it's accurate that few users will want gnutls.

[1]: https://glyph.twistedmatrix.com/2015/11/editor-malware.html

> I've expressed the view before on this list that the same should apply
> for the various options for libraries that allow emacs to view
> bitmap-graphics files, again a feature that few people are ever likely
> to use.

Yes, in Bug#25317 [2].  I was going to to add an option to make that
possible, but I didn't get around to finishing it at the time.

[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25317#13

> I strongly recommend that configure.ac be revised so that all
> --with-XXX=[no|yes] options allow configuration and building to
> proceed, regardless of their settings.  It is just too painful to have
> to spend several unnecessary hours restarting builds to work around
> the current undesirable behavior.

Here's a patch now, which should give the behaviour you want when
passing --with-all=maybe to ./configure.  Unfortunately, it's probably
too late to get this in for Emacs 26, but hopefully we can smooth things
out for version 27.

v1-0001-Support-.-configure-with-all-maybe.patch
Description: patch

And here is the equivalent for configure, in case you don't have
autoconf handy:

configure.diff
Description: with-all=maybe patch for configure

> 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