From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 17 19:31:48 2017 Received: (at submit) by debbugs.gnu.org; 17 Oct 2017 23:31:48 +0000 Received: from localhost ([127.0.0.1]:46751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4bKn-0005qF-WE for submit@debbugs.gnu.org; Tue, 17 Oct 2017 19:31:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4bKl-0005q0-DE for submit@debbugs.gnu.org; Tue, 17 Oct 2017 19:31:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e4bKe-00026h-Ej for submit@debbugs.gnu.org; Tue, 17 Oct 2017 19:31:34 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49068) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e4bKe-00026d-B4 for submit@debbugs.gnu.org; Tue, 17 Oct 2017 19:31:32 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e4bKc-0001sE-GH for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2017 19:31:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e4bKX-000259-UH for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2017 19:31:30 -0400 Received: from mail.math.utah.edu ([155.101.98.135]:35168) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e4bKX-00024g-Lp for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2017 19:31:25 -0400 Received: from gamma.math.utah.edu (gamma.math.utah.edu [155.101.96.20]) by mail.math.utah.edu (8.14.8/8.14.8) with ESMTP id v9HNVHEE016035; Tue, 17 Oct 2017 17:31:22 -0600 (MDT) Received: from gamma.math.utah.edu (localhost [127.0.0.1]) by gamma.math.utah.edu (8.15.1/8.15.1) with ESMTP id v9HNVHge068662; Tue, 17 Oct 2017 17:31:17 -0600 Received: (from beebe@localhost) by gamma.math.utah.edu (8.15.1/8.15.1/Submit) id v9HNVHw1068660; Tue, 17 Oct 2017 17:31:17 -0600 Date: Tue, 17 Oct 2017 17:31:17 -0600 From: "Nelson H. F. Beebe" To: bug-gnu-emacs@gnu.org X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: [bug-gnu-emacs] emacs-26.0.90 build feedback Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.8 (mail.math.utah.edu [155.101.98.135]); Tue, 17 Oct 2017 17:31:22 -0600 (MDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: beebe@math.utah.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 17 23:41:23 2017 Received: (at 28882) by debbugs.gnu.org; 18 Oct 2017 03:41:23 +0000 Received: from localhost ([127.0.0.1]:47072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4fEQ-0005YN-3x for submit@debbugs.gnu.org; Tue, 17 Oct 2017 23:41:22 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:51145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4fEK-0005Y4-JC for 28882@debbugs.gnu.org; Tue, 17 Oct 2017 23:41:18 -0400 Received: by mail-it0-f44.google.com with SMTP id 72so5028697itl.5 for <28882@debbugs.gnu.org>; Tue, 17 Oct 2017 20:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=pGeIJlDsvYV61AxQxKHTgTZW/xDKS25ZQNMyjYlxkpY=; b=epUH7CumXICpCdLqjYTd3TaiEMR9XWwbkZrA7S7pferlc47vmkLU4TXZzHfaZ4h5dB vccBPLQmGpx9pggOu/LnFkKI4q6AsoRj4FUxi8zKlwe5i9HbfjdG1Uv9wVVkKA9dKiKi uNPy3oh8me/f6KzPxYDnP4JhwCHXKVVXkPVJqfeP0ASYUNBYLRNTd2BiHObVESXCXU7s /xzYp8NMeAk3a0tUj+Lerl2dT4rBs86DmCsgP9SiaOxMWC91Jk2YHc9eBJraMz6W4ftY +69EXhv0/jTxKB0OfirGNAjcVDzltat3StRTPIMzNEPC6TdBkkf2v8YkUC4tRmmSHJBe L86w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=pGeIJlDsvYV61AxQxKHTgTZW/xDKS25ZQNMyjYlxkpY=; b=H0XjYcAyeVVxND2b3dPzrndBlV4dQaTVxSgVrwird5VykYtR5RDabmLdjlZ4HJni3Z iy7uKCMXG0V8k7w3SmhCDsw+ax4lF5iqsyjEX6nt+BMeAPGcIIVmvoWrFbrfnr3iZlNz dj+1gBydB/PABqX8fPQDhuwggcz1bWcErfE8hVEi/jxAT6AnnYEZkUTzZb54lVdVIFkp ATbUY4oIT3WKjgadwU0NYUqlwRIE764A2UYQhrXbxsIv+QFcBgFPJa3ulttBPdPLXPRp 62sR5FyN8Ynw1wAaoxwsi4LfW99Luy76n+bm3MhNizgM+5ESolxGGuFCA1/3Vxhvbggb atQQ== X-Gm-Message-State: AMCzsaXUdEj0LS2zS2EsIo2zbM0aw8VQ9P58PeszLPPxmMUN5IuxmyxC UMzXOQW7PgqN9ulch42JICX91g== X-Google-Smtp-Source: ABhQp+QpxRFReYSfr6/hGZ0kd5853v0TXElAm93NFZs6CAb+SiYvA3K7VcBLTGVY3wjN75AlMp2q3g== X-Received: by 10.36.13.19 with SMTP id 19mr7764054itx.107.1508298070765; Tue, 17 Oct 2017 20:41:10 -0700 (PDT) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id a31sm5976198itj.7.2017.10.17.20.41.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Oct 2017 20:41:09 -0700 (PDT) From: Noam Postavsky To: "Nelson H. F. Beebe" Subject: Re: bug#28882: [bug-gnu-emacs] emacs-26.0.90 build feedback References: Date: Tue, 17 Oct 2017 23:41:07 -0400 In-Reply-To: (Nelson H. F. Beebe's message of "Tue, 17 Oct 2017 17:31:17 -0600") Message-ID: <87vajdf7ho.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 28882 Cc: 28882@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --=-=-= Content-Type: text/plain "Nelson H. F. Beebe" 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. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=v1-0001-Support-.-configure-with-all-maybe.patch Content-Description: patch >From facc909306885f013843ae48b78d916626c6b55f Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Tue, 17 Oct 2017 21:17:53 -0400 Subject: [PATCH v1] Support ./configure --with-all=maybe * configure.ac: Change all --with-foo options to accept 'maybe' as a synonym for 'yes' (except that there's no error if the option can't be used). --- configure.ac | 67 ++++++++++++++++++++++++++++++------------------------------ 1 file changed, 34 insertions(+), 33 deletions(-) diff --git a/configure.ac b/configure.ac index 63324c2c7c..0ef9ca5147 100644 --- a/configure.ac +++ b/configure.ac @@ -243,7 +243,7 @@ AC_DEFUN installed])], [], [with_mailutils=$with_features - if test "$with_mailutils" = yes; then + if test "$with_mailutils" != no; then (movemail --version) >/dev/null 2>&1 || with_mailutils=no fi]) if test "$with_mailutils" = no; then @@ -302,9 +302,9 @@ AC_DEFUN [compile with sound support (VALUE one of: yes, alsa, oss, bsd-ossaudio, no; default yes). Only for GNU/Linux, FreeBSD, NetBSD, MinGW, Cygwin.])], [ case "${withval}" in - yes|no|alsa|oss|bsd-ossaudio) val=$withval ;; + yes|no|maybe|alsa|oss|bsd-ossaudio) val=$withval ;; *) AC_MSG_ERROR(['--with-sound=$withval' is invalid; -this option's value should be 'yes', 'no', 'alsa', 'oss', or 'bsd-ossaudio'.]) +this option's value should be 'yes', 'no', 'maybe', 'alsa', 'oss', or 'bsd-ossaudio'.]) ;; esac with_sound=$val @@ -316,10 +316,11 @@ AC_DEFUN dnl added later on when we find the file name of X, and it's best to dnl keep them together visually. AC_ARG_WITH([x-toolkit],[AS_HELP_STRING([--with-x-toolkit=KIT], - [use an X toolkit (KIT one of: yes or gtk, gtk2, gtk3, lucid or athena, motif, no)])], + [use an X toolkit (KIT one of: yes or gtk, gtk2, gtk3, lucid or athena, motif, maybe, no)])], [ case "${withval}" in y | ye | yes ) val=gtk ;; n | no ) val=no ;; + maybe ) val=maybe ;; l | lu | luc | luci | lucid ) val=lucid ;; a | at | ath | athe | athen | athena ) val=athena ;; m | mo | mot | moti | motif ) val=motif ;; @@ -328,7 +329,7 @@ AC_DEFUN gtk3 ) val=gtk3 ;; * ) AC_MSG_ERROR(['--with-x-toolkit=$withval' is invalid; -this option's value should be 'yes', 'no', 'lucid', 'athena', 'motif', 'gtk', +this option's value should be 'yes', 'no', 'maybe', 'lucid', 'athena', 'motif', 'gtk', 'gtk2' or 'gtk3'. 'yes' and 'gtk' are synonyms. 'athena' and 'lucid' are synonyms.]) ;; @@ -337,7 +338,7 @@ AC_DEFUN ]) OPTION_DEFAULT_OFF([wide-int], [prefer wide Emacs integers (typically 62-bit); allows buffer and string size up to 2GB on 32-bit hosts, at the cost of 10% to 30% slowdown of Lisp interpreter and larger memory footprint]) -if test "$with_wide_int" = yes; then +if test "$with_wide_int" != no; then AC_DEFINE([WIDE_EMACS_INT], 1, [Use long long for EMACS_INT if available.]) fi @@ -384,13 +385,14 @@ AC_DEFUN [ case "${withval}" in y | ye | yes ) val=yes ;; n | no ) val=no ;; + maybe ) val=maybe ;; i | in | ino | inot | inoti | inotif | inotify ) val=inotify ;; k | kq | kqu | kque | kqueu | kqueue ) val=kqueue ;; g | gf | gfi | gfil | gfile ) val=gfile ;; w | w3 | w32 ) val=w32 ;; * ) AC_MSG_ERROR(['--with-file-notification=$withval' is invalid; -this option's value should be 'yes', 'no', 'inotify', 'kqueue', 'gfile' or 'w32'. -'yes' is a synonym for 'w32' on MS-Windows, for 'no' on Nextstep, +this option's value should be 'yes', 'no', 'maybe', 'inotify', 'kqueue', 'gfile' or 'w32'. +'yes' and 'maybe' are a synonyms for 'w32' on MS-Windows, for 'no' on Nextstep, otherwise for the first of 'inotify', 'kqueue' or 'gfile' that is usable.]) ;; esac @@ -423,7 +425,7 @@ AC_DEFUN gamegroup= case ${with_gameuser} in '' | no) ;; - yes) gamegroup=games ;; + yes | maybe) gamegroup=games ;; :*) gamegroup=${with_gameuser#:} ;; *) gameuser=${with_gameuser} ;; esac @@ -1622,7 +1624,7 @@ AC_DEFUN fi AC_SUBST(LIBSOUND) - if test "${with_sound}" = "alsa" || test "${with_sound}" = "yes"; then + if test "${with_sound}" = "alsa" || test "${with_sound}" = "yes" || test "${with_sound}" = "maybe" ; then ALSA_REQUIRED=1.0.0 ALSA_MODULES="alsa >= $ALSA_REQUIRED" EMACS_CHECK_MODULES([ALSA], [$ALSA_MODULES]) @@ -2357,7 +2359,7 @@ AC_DEFUN AC_MSG_CHECKING([for thread support]) threads_enabled=no -if test "$with_threads" = yes; then +if test "$with_threads" != no; then if test "$emacs_cv_pthread_lib" != no; then AC_DEFINE(THREADS_ENABLED, 1, [Define to 1 if you want elisp thread support.]) @@ -2729,7 +2731,7 @@ AC_DEFUN dnl other platforms. HAVE_DBUS=no DBUS_OBJ= -if test "${with_dbus}" = "yes"; then +if test "${with_dbus}" != "no"; then EMACS_CHECK_MODULES([DBUS], [dbus-1 >= 1.0]) if test "$HAVE_DBUS" = yes; then AC_DEFINE(HAVE_DBUS, 1, [Define to 1 if using D-Bus.]) @@ -2754,7 +2756,7 @@ AC_DEFUN dnl GSettings has been tested under GNU/Linux only. HAVE_GSETTINGS=no -if test "${HAVE_X11}" = "yes" && test "${with_gsettings}" = "yes"; then +if test "${HAVE_X11}" = "yes" && test "${with_gsettings}" != "no"; then EMACS_CHECK_MODULES([GSETTINGS], [gio-2.0 >= 2.26]) if test "$HAVE_GSETTINGS" = "yes"; then old_CFLAGS=$CFLAGS @@ -2818,7 +2820,7 @@ AC_DEFUN dnl SELinux is available for GNU/Linux only. HAVE_LIBSELINUX=no LIBSELINUX_LIBS= -if test "${with_selinux}" = "yes"; then +if test "${with_selinux}" != "no"; then AC_CHECK_LIB([selinux], [lgetfilecon], HAVE_LIBSELINUX=yes, HAVE_LIBSELINUX=no) if test "$HAVE_LIBSELINUX" = yes; then AC_DEFINE(HAVE_LIBSELINUX, 1, [Define to 1 if using SELinux.]) @@ -2828,7 +2830,7 @@ AC_DEFUN AC_SUBST(LIBSELINUX_LIBS) HAVE_GNUTLS=no -if test "${with_gnutls}" = "yes" ; then +if test "${with_gnutls}" != "no" ; then EMACS_CHECK_MODULES([LIBGNUTLS], [gnutls >= 2.12.2], [HAVE_GNUTLS=yes], [HAVE_GNUTLS=no]) if test "${HAVE_GNUTLS}" = "yes"; then @@ -2845,7 +2847,7 @@ AC_DEFUN AC_SUBST(LIBGNUTLS_CFLAGS) HAVE_LIBSYSTEMD=no -if test "${with_libsystemd}" = "yes" ; then +if test "${with_libsystemd}" != "no" ; then dnl This code has been tested with libsystemd 222 and later. dnl FIXME: Find the earliest version number for which Emacs should work, dnl and change '222' to that number. @@ -2869,7 +2871,7 @@ AC_DEFUN this is only supported on MS-Windows native and MinGW32 builds. Consider using gfile instead.]) ;; - w32,* | yes,mingw32) + w32,* | yes,mingw32 | maybe,mingw32) AC_CHECK_HEADER(windows.h) if test "$ac_cv_header_windows_h" = yes ; then AC_DEFINE(HAVE_W32NOTIFY, 1, [Define to 1 to use w32notify.]) @@ -2880,7 +2882,7 @@ AC_DEFUN dnl inotify is available only on GNU/Linux. case $with_file_notification,$NOTIFY_OBJ in - inotify, | yes,) + inotify, | yes, | maybe,) AC_CHECK_HEADER(sys/inotify.h) if test "$ac_cv_header_sys_inotify_h" = yes ; then AC_CHECK_FUNC(inotify_init1) @@ -2894,7 +2896,7 @@ AC_DEFUN dnl kqueue is available on BSD-like systems. case $with_file_notification,$NOTIFY_OBJ in - kqueue,* | yes,) + kqueue,* | yes, | maybe,) EMACS_CHECK_MODULES([KQUEUE], [libkqueue]) if test "$HAVE_KQUEUE" = "yes"; then AC_DEFINE(HAVE_KQUEUE, 1, [Define to 1 to use kqueue.]) @@ -2917,7 +2919,7 @@ AC_DEFUN dnl has been added in glib 2.24. It has been tested under dnl GNU/Linux only. case $with_file_notification,$NOTIFY_OBJ in - gfile,* | yes,) + gfile,* | yes, |maybe,) if test "${HAVE_NS}" = yes; then AC_MSG_ERROR(['--with-file-notification=gfile' is not supported in NextStep builds. Consider kqueue instead.]) @@ -2934,7 +2936,7 @@ AC_DEFUN esac case $with_file_notification,$NOTIFY_OBJ in - yes,* | no,* | *,?*) ;; + yes,* | no,* | maybe,* | *,?*) ;; *) AC_MSG_ERROR([File notification '$with_file_notification' requested but requirements not found.]) ;; esac @@ -3298,14 +3300,13 @@ AC_DEFUN EMACS_CHECK_MODULES(CAIRO, $CAIRO_MODULE) if test $HAVE_CAIRO = yes; then AC_DEFINE(USE_CAIRO, 1, [Define to 1 if using cairo.]) - else + CFLAGS="$CFLAGS $CAIRO_CFLAGS" + LIBS="$LIBS $CAIRO_LIBS" + AC_SUBST(CAIRO_CFLAGS) + AC_SUBST(CAIRO_LIBS) + elif test "${with_cairo}" = "yes" ; then AC_MSG_ERROR([cairo requested but not found.]) fi - - CFLAGS="$CFLAGS $CAIRO_CFLAGS" - LIBS="$LIBS $CAIRO_LIBS" - AC_SUBST(CAIRO_CFLAGS) - AC_SUBST(CAIRO_LIBS) fi fi @@ -3672,18 +3673,18 @@ AC_DEFUN MISSING= WITH_NO= if test "${HAVE_X11}" = "yes"; then - test "${with_xpm}" != "no" && test "${HAVE_XPM}" != "yes" && + test "${with_xpm}" = "yes" && test "${HAVE_XPM}" != "yes" && MISSING="libXpm" && WITH_NO="--with-xpm=no" - test "${with_jpeg}" != "no" && test "${HAVE_JPEG}" != "yes" && + test "${with_jpeg}" = "yes" && test "${HAVE_JPEG}" != "yes" && MISSING="$MISSING libjpeg" && WITH_NO="$WITH_NO --with-jpeg=no" - test "${with_png}" != "no" && test "${HAVE_PNG}" != "yes" && + test "${with_png}" = "yes" && test "${HAVE_PNG}" != "yes" && MISSING="$MISSING libpng" && WITH_NO="$WITH_NO --with-png=no" - test "${with_gif}" != "no" && test "${HAVE_GIF}" != "yes" && + test "${with_gif}" = "yes" && test "${HAVE_GIF}" != "yes" && MISSING="$MISSING libgif/libungif" && WITH_NO="$WITH_NO --with-gif=no" - test "${with_tiff}" != "no" && test "${HAVE_TIFF}" != "yes" && + test "${with_tiff}" = "yes" && test "${HAVE_TIFF}" != "yes" && MISSING="$MISSING libtiff" && WITH_NO="$WITH_NO --with-tiff=no" fi -test "${with_gnutls}" != "no" && test "${HAVE_GNUTLS}" != "yes" && +test "${with_gnutls}" = "yes" && test "${HAVE_GNUTLS}" != "yes" && MISSING="$MISSING gnutls" && WITH_NO="$WITH_NO --with-gnutls=no" if test "X${MISSING}" != X; then AC_MSG_ERROR([The following required libraries were not found: -- 2.11.0 --=-=-= Content-Type: text/plain And here is the equivalent for configure, in case you don't have autoconf handy: --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=configure.diff Content-Description: with-all=maybe patch for configure --- configure 2017-10-17 22:10:41.684538677 -0400 +++ configure.with-maybe 2017-10-17 22:10:20.768469411 -0400 @@ -2370,7 +2370,7 @@ oss, bsd-ossaudio, no; default yes). Only for GNU/Linux, FreeBSD, NetBSD, MinGW, Cygwin. --with-x-toolkit=KIT use an X toolkit (KIT one of: yes or gtk, gtk2, - gtk3, lucid or athena, motif, no) + gtk3, lucid or athena, motif, maybe, no) --with-wide-int prefer wide Emacs integers (typically 62-bit); allows buffer and string size up to 2GB on 32-bit hosts, at the cost of 10% to 30% slowdown of Lisp @@ -4168,7 +4168,7 @@ withval=$with_mailutils; else with_mailutils=$with_features - if test "$with_mailutils" = yes; then + if test "$with_mailutils" != no; then (movemail --version) >/dev/null 2>&1 || with_mailutils=no fi fi @@ -4269,9 +4269,9 @@ # Check whether --with-sound was given. if test "${with_sound+set}" = set; then : withval=$with_sound; case "${withval}" in - yes|no|alsa|oss|bsd-ossaudio) val=$withval ;; + yes|no|maybe|alsa|oss|bsd-ossaudio) val=$withval ;; *) as_fn_error $? "'--with-sound=$withval' is invalid; -this option's value should be 'yes', 'no', 'alsa', 'oss', or 'bsd-ossaudio'." "$LINENO" 5 +this option's value should be 'yes', 'no', 'maybe', 'alsa', 'oss', or 'bsd-ossaudio'." "$LINENO" 5 ;; esac with_sound=$val @@ -4287,6 +4287,7 @@ withval=$with_x_toolkit; case "${withval}" in y | ye | yes ) val=gtk ;; n | no ) val=no ;; + maybe ) val=maybe ;; l | lu | luc | luci | lucid ) val=lucid ;; a | at | ath | athe | athen | athena ) val=athena ;; m | mo | mot | moti | motif ) val=motif ;; @@ -4295,7 +4296,7 @@ gtk3 ) val=gtk3 ;; * ) as_fn_error $? "'--with-x-toolkit=$withval' is invalid; -this option's value should be 'yes', 'no', 'lucid', 'athena', 'motif', 'gtk', +this option's value should be 'yes', 'no', 'maybe', 'lucid', 'athena', 'motif', 'gtk', 'gtk2' or 'gtk3'. 'yes' and 'gtk' are synonyms. 'athena' and 'lucid' are synonyms." "$LINENO" 5 ;; @@ -4313,7 +4314,7 @@ with_wide_int=no fi -if test "$with_wide_int" = yes; then +if test "$with_wide_int" != no; then $as_echo "#define WIDE_EMACS_INT 1" >>confdefs.h @@ -4554,13 +4555,14 @@ withval=$with_file_notification; case "${withval}" in y | ye | yes ) val=yes ;; n | no ) val=no ;; + maybe ) val=maybe ;; i | in | ino | inot | inoti | inotif | inotify ) val=inotify ;; k | kq | kqu | kque | kqueu | kqueue ) val=kqueue ;; g | gf | gfi | gfil | gfile ) val=gfile ;; w | w3 | w32 ) val=w32 ;; * ) as_fn_error $? "'--with-file-notification=$withval' is invalid; -this option's value should be 'yes', 'no', 'inotify', 'kqueue', 'gfile' or 'w32'. -'yes' is a synonym for 'w32' on MS-Windows, for 'no' on Nextstep, +this option's value should be 'yes', 'no', 'maybe', 'inotify', 'kqueue', 'gfile' or 'w32'. +'yes' and 'maybe' are a synonyms for 'w32' on MS-Windows, for 'no' on Nextstep, otherwise for the first of 'inotify', 'kqueue' or 'gfile' that is usable." "$LINENO" 5 ;; esac @@ -4615,7 +4617,7 @@ gamegroup= case ${with_gameuser} in '' | no) ;; - yes) gamegroup=games ;; + yes | maybe) gamegroup=games ;; :*) gamegroup=${with_gameuser#:} ;; *) gameuser=${with_gameuser} ;; esac @@ -9635,7 +9637,7 @@ fi - if test "${with_sound}" = "alsa" || test "${with_sound}" = "yes"; then + if test "${with_sound}" = "alsa" || test "${with_sound}" = "yes" || test "${with_sound}" = "maybe" ; then ALSA_REQUIRED=1.0.0 ALSA_MODULES="alsa >= $ALSA_REQUIRED" @@ -11735,7 +11737,7 @@ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for thread support" >&5 $as_echo_n "checking for thread support... " >&6; } threads_enabled=no -if test "$with_threads" = yes; then +if test "$with_threads" != no; then if test "$emacs_cv_pthread_lib" != no; then $as_echo "#define THREADS_ENABLED 1" >>confdefs.h @@ -12715,7 +12717,7 @@ HAVE_DBUS=no DBUS_OBJ= -if test "${with_dbus}" = "yes"; then +if test "${with_dbus}" != "no"; then pkg_failed=no { $as_echo "$as_me:${as_lineno-$LINENO}: checking for DBUS" >&5 @@ -12820,7 +12822,7 @@ HAVE_GSETTINGS=no -if test "${HAVE_X11}" = "yes" && test "${with_gsettings}" = "yes"; then +if test "${HAVE_X11}" = "yes" && test "${with_gsettings}" != "no"; then pkg_failed=no { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GSETTINGS" >&5 @@ -13117,7 +13119,7 @@ HAVE_LIBSELINUX=no LIBSELINUX_LIBS= -if test "${with_selinux}" = "yes"; then +if test "${with_selinux}" != "no"; then { $as_echo "$as_me:${as_lineno-$LINENO}: checking for lgetfilecon in -lselinux" >&5 $as_echo_n "checking for lgetfilecon in -lselinux... " >&6; } if ${ac_cv_lib_selinux_lgetfilecon+:} false; then : @@ -13170,7 +13172,7 @@ HAVE_GNUTLS=no -if test "${with_gnutls}" = "yes" ; then +if test "${with_gnutls}" != "no" ; then pkg_failed=no { $as_echo "$as_me:${as_lineno-$LINENO}: checking for LIBGNUTLS" >&5 @@ -13259,7 +13261,7 @@ HAVE_LIBSYSTEMD=no -if test "${with_libsystemd}" = "yes" ; then +if test "${with_libsystemd}" != "no" ; then pkg_failed=no { $as_echo "$as_me:${as_lineno-$LINENO}: checking for LIBSYSTEMD" >&5 @@ -13351,7 +13353,7 @@ this is only supported on MS-Windows native and MinGW32 builds. Consider using gfile instead." "$LINENO" 5 ;; - w32,* | yes,mingw32) + w32,* | yes,mingw32 | maybe,mingw32) ac_fn_c_check_header_mongrel "$LINENO" "windows.h" "ac_cv_header_windows_h" "$ac_includes_default" if test "x$ac_cv_header_windows_h" = xyes; then : @@ -13368,7 +13370,7 @@ esac case $with_file_notification,$NOTIFY_OBJ in - inotify, | yes,) + inotify, | yes, | maybe,) ac_fn_c_check_header_mongrel "$LINENO" "sys/inotify.h" "ac_cv_header_sys_inotify_h" "$ac_includes_default" if test "x$ac_cv_header_sys_inotify_h" = xyes; then : @@ -13392,7 +13394,7 @@ esac case $with_file_notification,$NOTIFY_OBJ in - kqueue,* | yes,) + kqueue,* | yes, | maybe,) pkg_failed=no { $as_echo "$as_me:${as_lineno-$LINENO}: checking for KQUEUE" >&5 @@ -13542,7 +13544,7 @@ esac case $with_file_notification,$NOTIFY_OBJ in - gfile,* | yes,) + gfile,* | yes, |maybe,) if test "${HAVE_NS}" = yes; then as_fn_error $? "'--with-file-notification=gfile' is not supported in NextStep builds. Consider kqueue instead." "$LINENO" 5 @@ -13632,7 +13634,7 @@ esac case $with_file_notification,$NOTIFY_OBJ in - yes,* | no,* | *,?*) ;; + yes,* | no,* | maybe,* | *,?*) ;; *) as_fn_error $? "File notification '$with_file_notification' requested but requirements not found." "$LINENO" 5 ;; esac @@ -14817,14 +14819,13 @@ $as_echo "#define USE_CAIRO 1" >>confdefs.h - else - as_fn_error $? "cairo requested but not found." "$LINENO" 5 - fi - - CFLAGS="$CFLAGS $CAIRO_CFLAGS" - LIBS="$LIBS $CAIRO_LIBS" + CFLAGS="$CFLAGS $CAIRO_CFLAGS" + LIBS="$LIBS $CAIRO_LIBS" + elif test "${with_cairo}" = "yes" ; then + as_fn_error $? "cairo requested but not found." "$LINENO" 5 + fi fi fi @@ -15768,18 +15769,18 @@ MISSING= WITH_NO= if test "${HAVE_X11}" = "yes"; then - test "${with_xpm}" != "no" && test "${HAVE_XPM}" != "yes" && + test "${with_xpm}" = "yes" && test "${HAVE_XPM}" != "yes" && MISSING="libXpm" && WITH_NO="--with-xpm=no" - test "${with_jpeg}" != "no" && test "${HAVE_JPEG}" != "yes" && + test "${with_jpeg}" = "yes" && test "${HAVE_JPEG}" != "yes" && MISSING="$MISSING libjpeg" && WITH_NO="$WITH_NO --with-jpeg=no" - test "${with_png}" != "no" && test "${HAVE_PNG}" != "yes" && + test "${with_png}" = "yes" && test "${HAVE_PNG}" != "yes" && MISSING="$MISSING libpng" && WITH_NO="$WITH_NO --with-png=no" - test "${with_gif}" != "no" && test "${HAVE_GIF}" != "yes" && + test "${with_gif}" = "yes" && test "${HAVE_GIF}" != "yes" && MISSING="$MISSING libgif/libungif" && WITH_NO="$WITH_NO --with-gif=no" - test "${with_tiff}" != "no" && test "${HAVE_TIFF}" != "yes" && + test "${with_tiff}" = "yes" && test "${HAVE_TIFF}" != "yes" && MISSING="$MISSING libtiff" && WITH_NO="$WITH_NO --with-tiff=no" fi -test "${with_gnutls}" != "no" && test "${HAVE_GNUTLS}" != "yes" && +test "${with_gnutls}" = "yes" && test "${HAVE_GNUTLS}" != "yes" && MISSING="$MISSING gnutls" && WITH_NO="$WITH_NO --with-gnutls=no" if test "X${MISSING}" != X; then as_fn_error $? "The following required libraries were not found: --=-=-= Content-Type: text/plain > 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 18 09:31:27 2017 Received: (at 28882) by debbugs.gnu.org; 18 Oct 2017 13:31:27 +0000 Received: from localhost ([127.0.0.1]:47401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4oRS-0002bn-VN for submit@debbugs.gnu.org; Wed, 18 Oct 2017 09:31:27 -0400 Received: from mail.math.utah.edu ([155.101.98.135]:44934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4oRR-0002ba-S6 for 28882@debbugs.gnu.org; Wed, 18 Oct 2017 09:31:26 -0400 Received: from gamma.math.utah.edu (gamma.math.utah.edu [155.101.96.20]) by mail.math.utah.edu (8.14.8/8.14.8) with ESMTP id v9IDVB53014148; Wed, 18 Oct 2017 07:31:16 -0600 (MDT) Received: from gamma.math.utah.edu (localhost [127.0.0.1]) by gamma.math.utah.edu (8.15.1/8.15.1) with ESMTP id v9IDVA1A009634; Wed, 18 Oct 2017 07:31:10 -0600 Received: (from beebe@localhost) by gamma.math.utah.edu (8.15.1/8.15.1/Submit) id v9IDVAi9009632; Wed, 18 Oct 2017 07:31:10 -0600 Date: Wed, 18 Oct 2017 07:31:10 -0600 From: "Nelson H. F. Beebe" To: 28882@debbugs.gnu.org, Noam Postavsky X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: bug#28882: [bug-gnu-emacs] emacs-26.0.90 build feedback Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.8 (mail.math.utah.edu [155.101.98.135]); Wed, 18 Oct 2017 07:31:17 -0600 (MDT) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 28882 Cc: beebe@math.utah.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Thanks, Noam, for your extensive response to my long report yesterday of my build experience for emacs-26.0.90 on, initially, 160 different operating systems in our test lab. Since that report, with manual tweaks, such as hiding /usr/local during builds, and restoring it before installs, I've increased the number of successes to 135 systems. This reply addresses the issue of Alpine Linux. This morning, I read the section in etc/PROBLEMS on address space layout randomization (ASLR), and on our Alpine systems, tried the trick (as root) of echo 0 > /proc/sys/kernel/randomize_va_space before doing a build with env CONFIG_SITE= ./configure --prefix=$L --with-pop && make all check [L is a personal variable for our default prefix on newer systems]. I'm pleased to report that the builds on Alpine Linux succeeded, and emacs is now fully functional on all of them, which report their versions in /etc/alpine-release as 3.4.6, 3.5.2, 3.6.0, and 3.6.2. I'm now looking into similar issues on Hardened BSD 11.1-STABLE-HBSD and 12.0-CURRENT, where the build succeeds up to the point of the memory dump, and then fails with Dumping under the name emacs 11323200 of 33554432 static heap bytes used gmake[1]: *** [Makefile:738: bootstrap-emacs] Segmentation fault I'll report back on this list if/when I learn more. ------------------------------------------------------------------------------- - 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@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 18 10:17:31 2017 Received: (at 28882) by debbugs.gnu.org; 18 Oct 2017 14:17:31 +0000 Received: from localhost ([127.0.0.1]:48421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4pA2-0003yw-Qt for submit@debbugs.gnu.org; Wed, 18 Oct 2017 10:17:31 -0400 Received: from mail.math.utah.edu ([155.101.98.135]:47973) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4pA1-0003yh-GP for 28882@debbugs.gnu.org; Wed, 18 Oct 2017 10:17:30 -0400 Received: from gamma.math.utah.edu (gamma.math.utah.edu [155.101.96.20]) by mail.math.utah.edu (8.14.8/8.14.8) with ESMTP id v9IEHEo3022277; Wed, 18 Oct 2017 08:17:19 -0600 (MDT) Received: from gamma.math.utah.edu (localhost [127.0.0.1]) by gamma.math.utah.edu (8.15.1/8.15.1) with ESMTP id v9IEHEkp013849; Wed, 18 Oct 2017 08:17:14 -0600 Received: (from beebe@localhost) by gamma.math.utah.edu (8.15.1/8.15.1/Submit) id v9IEHEbA013847; Wed, 18 Oct 2017 08:17:14 -0600 Date: Wed, 18 Oct 2017 08:17:14 -0600 From: "Nelson H. F. Beebe" To: 28882@debbugs.gnu.org, Noam Postavsky X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: bug#28882: [bug-gnu-emacs] emacs-26.0.90 build feedback Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.8 (mail.math.utah.edu [155.101.98.135]); Wed, 18 Oct 2017 08:17:21 -0600 (MDT) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 28882 Cc: beebe@math.utah.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) The emacs-26.0.90 etc/PROBLEMS file suggests another approach to work around kernel memory layout randomizations for Red Hat systems. Curiously, I had no difficulty building emacs-26.0.90 on CentOS 6 and 7 on x86-64 systems, and CentOS 5 IA-64 (Itanium), but on CentOS 5 x86 and x86-64, I get Dumping under the name emacs ************************************************** Warning: Your system has a gap between BSS and the heap (8467071 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 Today, as root, I ran # cat /proc/sys/kernel/exec-shield 1 # echo 0 > /proc/sys/kernel/exec-shield # cat /proc/sys/kernel/exec-shield 0 and then as an unprivileged user, restarted the make. Unlike on Alpine Linux, the kernel symbol-value change had no effect: the build still gets a segmentation fault. I then tried % ./src/temacs Loading loadup.el (source)... Using load-path (/local/build/cc/emacs-26.0.90/lisp) Loading emacs-lisp/byte-run... ... Finding pointers to doc strings...done Pure-hashed: 15477 strings, 4055 vectors, 40214 conses, 3919 bytecodes, 175 others At that point, a normal emacs X11 window appears on my screen, so most of emacs is working. However, the dumped executable is unusable: % ls -l src/*emacs -rwxrwxr-x 1 beebe sysstaff 84149492 Oct 18 07:40 src/emacs -rwxrwxr-x 1 beebe sysstaff 48352600 Oct 18 07:40 src/temacs % file src/emacs src/emacs: data % ./src/emacs src/emacs: Exec format error. Binary file not executable. % ldd ./src/emacs not a dynamic executable In CentOS 5 and 6, the exec-shield variable is 1 by default; it does not exist on CentOS 7. The latter instead has /proc/sys/kernel/randomize_va_space set to 2, but a successful dump to create src/emacs does not require changing that variable. Next, I tried another suggestion from etc/PROBLEMS: % rm src/emacs src/temacs $ bash $ export PATH=/bin:/usr/bin:/sbin:/usr/sbin $ setarch $(uname -m ) -R make That one succeeded in making a usable src/emacs executable on both x86 and x86-64 CentOS 5 systems, with /usr/local hidden; I then restored /usr/local and successfully installed emacs-26.0.90 on those servers. Thus, the build problems for emacs-26.0.90 on CentOS 5 are resolved, and my count of successes has increased to 138. ------------------------------------------------------------------------------- - 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@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 18 10:24:15 2017 Received: (at 28882) by debbugs.gnu.org; 18 Oct 2017 14:24:15 +0000 Received: from localhost ([127.0.0.1]:48436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4pGZ-0004AS-9N for submit@debbugs.gnu.org; Wed, 18 Oct 2017 10:24:15 -0400 Received: from mx2.suse.de ([195.135.220.15]:52178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4pGY-0004AK-6E for 28882@debbugs.gnu.org; Wed, 18 Oct 2017 10:24:14 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0CDF4ABC6; Wed, 18 Oct 2017 14:24:13 +0000 (UTC) From: Andreas Schwab To: "Nelson H. F. Beebe" Subject: Re: bug#28882: emacs-26.0.90 build feedback References: X-Yow: PIZZA!! Date: Wed, 18 Oct 2017 16:24:12 +0200 In-Reply-To: (Nelson H. F. Beebe's message of "Wed, 18 Oct 2017 07:31:10 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 28882 Cc: Noam Postavsky , 28882@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On Okt 18 2017, "Nelson H. F. Beebe" wrote: > I'm now looking into similar issues on Hardened BSD 11.1-STABLE-HBSD > and 12.0-CURRENT, where the build succeeds up to the point of the > memory dump, and then fails with > > Dumping under the name emacs > 11323200 of 33554432 static heap bytes used > gmake[1]: *** [Makefile:738: bootstrap-emacs] Segmentation fault Does it help to add -no-pie to LDFLAGS? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 18 13:58:32 2017 Received: (at 28882) by debbugs.gnu.org; 18 Oct 2017 17:58:32 +0000 Received: from localhost ([127.0.0.1]:48578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4sbw-0001eN-6M for submit@debbugs.gnu.org; Wed, 18 Oct 2017 13:58:32 -0400 Received: from mail.math.utah.edu ([155.101.98.135]:63721) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4sbt-0001du-A2 for 28882@debbugs.gnu.org; Wed, 18 Oct 2017 13:58:29 -0400 Received: from gamma.math.utah.edu (gamma.math.utah.edu [155.101.96.20]) by mail.math.utah.edu (8.14.8/8.14.8) with ESMTP id v9IHwCr1027999; Wed, 18 Oct 2017 11:58:17 -0600 (MDT) Received: from gamma.math.utah.edu (localhost [127.0.0.1]) by gamma.math.utah.edu (8.15.1/8.15.1) with ESMTP id v9IHwB9M036521; Wed, 18 Oct 2017 11:58:11 -0600 Received: (from beebe@localhost) by gamma.math.utah.edu (8.15.1/8.15.1/Submit) id v9IHwBIg036517; Wed, 18 Oct 2017 11:58:11 -0600 Date: Wed, 18 Oct 2017 11:58:11 -0600 From: "Nelson H. F. Beebe" To: 28882@debbugs.gnu.org, Noam Postavsky , Andreas Schwab X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: bug#28882: [bug-gnu-emacs] emacs-26.0.90 build feedback Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.8 (mail.math.utah.edu [155.101.98.135]); Wed, 18 Oct 2017 11:58:20 -0600 (MDT) X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 28882 Cc: beebe@math.utah.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Andreas Schwab asks about my build attempts for emacs-26.0.90 on HardenedBSD: >> Does it help to add -no-pie to LDFLAGS? For HardenedBSD 11.1-STABLE-HBSD (FreeBSD 11.1-STABLE-HBSD #0), that worked: rm src/emacs src/temacs gmake LDFLAGS=-no-pie I installed that version. I then tried the same on HardenedBSD 12.0-CURRENT (FreeBSD 12.0-CURRENT #0). It complained that the -no-pie option was unrecognized, so I retried with --no-pie: that was accepted, but there was still a segmentation fault at dump time. Next, based on the advice for NetBSD in etc/PROBLEMS about kernel parameters that control address-space layout randomization (ASLR), I looked to see what HardenedBSD had: # sysctl -a | grep -i aslr kern.features.hbsd_aslr: 1 options PAX_ASLR hardening.pax.aslr.status: 2 With those defaults, I get failure like this in the emacs build: Dumping under the name emacs 11323200 of 33554432 static heap bytes used gmake[1]: *** [Makefile:738: bootstrap-emacs] Segmentation fault In another window, as root, I then ran # sysctl kern.features.hbsd_aslr:0 sysctl: oid 'kern.features.hbsd_aslr' is read only # sysctl hardening.pax.aslr.status:0 hardening.pax.aslr.status: 2 -> 0 Then, back in the emacs build window, I ran % \rm src/emacs src/temacs % gmake ... ./temacs --batch --load loadup bootstrap Loading loadup.el (source)... Using load-path (/local/build/cc/emacs-26.0.90/lisp /local/build/cc/emacs-26.0.90/lisp/emacs-lisp /local/build/cc/emacs-26.0.90/lisp/language /local/build/cc/emacs-26.0.90/lisp/international /local/build/cc/emacs-26.0.90/lisp/textmodes /local/build/cc/emacs-26.0.90/lisp/vc) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... ... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name emacs 11323200 of 33554432 static heap bytes used 96055 pure bytes used mv -f emacs bootstrap-emacs gmake -C ../lisp compile-first EMACS="../src/bootstrap-emacs" gmake[2]: Entering directory '/local/build/cc/emacs-26.0.90/lisp' gmake[2]: Nothing to be done for 'compile-first'. gmake[2]: Leaving directory '/local/build/cc/emacs-26.0.90/lisp' gmake -C ../admin/unidata all EMACS="../../src/bootstrap-emacs" gmake[2]: Entering directory '/local/build/cc/emacs-26.0.90/admin/unidata' ELC uvs.elc elf_load_section: truncated ELF file gmake[2]: *** [Makefile:72: uvs.elc] Abort trap If I try to run the dumped emacs, I get % src/bootstrap-emacs --version elf_load_section: truncated ELF file Abort Thus, disabling the ASLR feature in HardenedBSD 12.0 DOES let temacs run to completion, but the result dumped emacs does not run correctly. As I final experiment, I ported over the 11.1 emacs installation directories to 12.0, and after installing some missing packages, and creating some symlinks to missing older library versions, I was able to get a usable emacs-26.0.90 on 12.0. However, that has to be viewed as a temporary stopgap. The number of dependent shared libraries is frighteningly large % ldd $B/nemacs |wc -l 96 so the import from 11.1 to 12.0 is fragile, and likely to break with future system updates on the 12.0 system. ------------------------------------------------------------------------------- - 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@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 12:19:18 2020 Received: (at 28882) by debbugs.gnu.org; 22 Aug 2020 16:19:18 +0000 Received: from localhost ([127.0.0.1]:51177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WEg-0000rt-FJ for submit@debbugs.gnu.org; Sat, 22 Aug 2020 12:19:18 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WEe-0000rc-Q0 for 28882@debbugs.gnu.org; Sat, 22 Aug 2020 12:19:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yz28ZfP+ZdHIL+6xdCOjnFMuhNU1M9s+P2uOmdheZ1U=; b=TbNVu17GFwlcDyC4PzxPsuQU00 rRKSdG8+I4eIvO2tJWlzcPL1WKHn0ROAuyot2dJowluFe3APIoKokHROKjsietIfslmgv5rLV4NuA VAtbJYcseycm+sOqk3WZjHCl0jpCDTWv7a9djQxfIG9xgs+8RgYOxxPtv3f5mXTKNVBA=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9WEV-0000x4-Ce; Sat, 22 Aug 2020 18:19:10 +0200 From: Lars Ingebrigtsen To: "Nelson H. F. Beebe" Subject: Re: bug#28882: [bug-gnu-emacs] emacs-26.0.90 build feedback References: X-Now-Playing: Old's _Formula_: "Last Look" Date: Sat, 22 Aug 2020 18:19:05 +0200 In-Reply-To: (Nelson H. F. Beebe's message of "Wed, 18 Oct 2017 07:31:10 -0600") Message-ID: <87lfi6irgm.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: "Nelson H. F. Beebe" writes: > 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. Cool! Is it possible to see the status of these builds anywhere? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 28882 Cc: Noam Postavsky , 28882@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Nelson H. F. Beebe" writes: > 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. Cool! Is it possible to see the status of these builds anywhere? > This reply addresses the issue of Alpine Linux. This morning, I read > the section in etc/PROBLEMS on address space layout randomization > (ASLR), and on our Alpine systems, tried the trick (as root) of > > echo 0 > /proc/sys/kernel/randomize_va_space > > before doing a build with > > env CONFIG_SITE= ./configure --prefix=$L --with-pop && make all check I think that newer Emacs versions should build with address randomisation just fine, so this should no longer be necessary. The other concrete issue in this bug report was that you have to say ./configure --with-gnutls=no (or ifavailable, these days), otherwise Emacs will refuse to build (if you have no gnutls libraries). I think that's a the correct choice, and leads to a whole lot fewer bug reports about packages etc not working. So I'm closing this bug report; if there's anything more to be done here, please respond to the debbugs mail address and we'll reopen. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 12:19:25 2020 Received: (at control) by debbugs.gnu.org; 22 Aug 2020 16:19:26 +0000 Received: from localhost ([127.0.0.1]:51180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WEn-0000sE-NE for submit@debbugs.gnu.org; Sat, 22 Aug 2020 12:19:25 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WEl-0000rr-9F for control@debbugs.gnu.org; Sat, 22 Aug 2020 12:19:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rwrvI6/jezqpzgR+sHOBvJ27jd59nPQxLp7M5/sooMM=; b=GtttBUrF/Q3GQKftCA3KkwdJvy /X5J7vA+eHcJhUFjTc7mhCOzcDqFVruewyNcDj+99FO1sLHOXaqRp+p5GnVLq/XiOONYz5TvoKW1Y vnmqU1OxP5w/XpaFX2wdzBOWgB5p/iV2ZJIE6EYx5HQQ3X+F5VmjYax4/Cko4KOR5bMY=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9WEd-0000xB-IG for control@debbugs.gnu.org; Sat, 22 Aug 2020 18:19:17 +0200 Date: Sat, 22 Aug 2020 18:19:14 +0200 Message-Id: <87k0xqirgd.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #28882 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 28882 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 28882 quit From unknown Fri Aug 15 15:35:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 20 Sep 2020 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator