Package: emacs;
Reported by: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Date: Tue, 17 Oct 2017 23:32:01 UTC
Severity: minor
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: "Nelson H. F. Beebe" <beebe <at> math.utah.edu> To: 28882 <at> debbugs.gnu.org Cc: beebe <at> math.utah.edu Subject: bug#28882: [bug-gnu-emacs] emacs-26.0.90 build feedback Date: Tue, 17 Oct 2017 17:31:17 -0600
I now have more than 230 build attempts for emacs-26.0.90 in our growing test lab with about 180 flavors of Unix(-like) operating systems. Of the initial 160 automated builds, 57 completed, and all that I had to do manually was the "make install" step (at my site, that is hidden in wrapper so that the installed executable is named nemacs, for new emacs, so as not to overwrite any existing version called emacs). 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. 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. With as many test systems as I have, it is utterly impractical to know in advance which of the --with-XXX=no options are needed to avoid configure-time termination. Even if I wrote down once what those options are for each system, subsequent system updates would likely invalidate those choices, as would different versions of emacs. On several of my systems, there are GIF, JPEG, PNG, RSVG, TIFF, ... libraries installed, but configure may still reject them because of version-number tests, or feature tests. 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. I still have a few systems where emacs-26.0.90 has not yet successfully been built and installed, and I'm continuing to work on finding solutions. However, I wanted to get this report posted now that I've done 125 successful installs. 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. 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. In no case has a build been stopped by emacs source code errors, but some builds were stopped by link-time failures to find particular functions. In most cases, I could later get a successful build by adding a suitable --with-XXX=no option to suppress use of a particular library. 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. Even though most Unix-(like) systems other than GNU Hurd and GNU/Linux have a gmake package, when bootstrapping a new system, usually the first GNU package that I'm likely to build is GNU tar, and the second, GNU emacs. That means that both need to be buildable with traditional make, and both are far too complex to do a build by manually running cc. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe <at> math.utah.edu - - 155 S 1400 E RM 233 beebe <at> acm.org beebe <at> computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.