From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: 20218@debbugs.gnu.org
Cc: beebe@math.utah.edu
Subject: bug#20218: emacs-24.5-rc1 build successes, and one failure
Date: Sat, 28 Mar 2015 09:19:26 -0600 (MDT) [thread overview]
Message-ID: <CMM.0.94.0.1427555966.beebe@psi.math.utah.edu> (raw)
I've now completed 111 build attempts for emacs-24.5-rc1 on 38 flavors
of Unix systems, and am pleased to report success on 37 of them:
DragonFlyBSD 3.6, 3.8, 3.9, 4.0 x86-64
GNU/Linux ArchLinux x86-64 and ARM
GNU/Linux Debian 6.0, 7.7, 8.0 x86-64
GNU/Linux Debian 7 SPARC
GNU/Linux Fedora 20 x86
GNU/Linux Fedora 21 and 22 x86-64
GNU/Linux OpenSUSE 11.4, 12.3, 13.2 x86-64
GNU/Linux Red Hat 5 IA-64 and x86
GNU/Linux Red Hat 5, 6, 7 x86-64
GNU/Linux Scientific Linux 6.5 x86-64
GNU/Linux Slackware 14 x86-64
GNU/Linux Ubuntu 14 x86
kFreeBSD 7.7 x86-64
Mac OS X 10.5.8 PowerPC-32
Mac OS X 10.7.5 x86-64
Mac OS X 10.10.2 x86-64
MirBSD 10 x86
NetBSD 5.0, 6.1 x86-64
OpenBSD 4.9, 5.1, 5.4, 5.5, 5.6 x86-64
OpenIndiana 11 x86-64
SGI IRIX MIPS R10000
Solaris 10 SPARC, x86, x86-64
Solaris 11 x86, x86-64
On about half, the build succeeded out of the box with my standard
automated build procedures. On the remainder, I had to manually add
various --with-XXX=no options to deal with missing, or out-of-date,
graphics libraries.
I therefore recommend that the configure scripts should be adjusted so
that failure to use any graphics library should just be prominently
recorded in the configure output, and then --with-XXX=no silently
assumed for that library. Doing so would significantly increase the
number of builds that succeed on the first try.
In three or four cases, I had to temporarily rename the /usr/local
tree during the build to hide it from gcc, which obnoxiously insists
on searching /usr/local/include before /usr/include, even when you
don't want it to. For that reason, and the fact that some of the BSD
distributions incorrectly use /usr/local for their package management
installations, on all new systems that we install, we replace
/usr/local by /usr/uumath as the tree for packages locally built and
installed from source code.
The one failure for my emacs-24.5-rc1 builds is this system:
GNU Hurd 8 (jessie) x86-64
I have previously successfully built emacs-24.3.90, emacs-24.3.92, and
emacs-24.3.94 on that system, and after several failures for
emacs-24.5-rc1, I retried with the identical PATH and other
environment variables and configure flags as for 24.3.94. Some of my
several attempts succeeded in building src/temacs, but all died like
this:
Loading version...
Loading widget...
Loading custom...
Required feature `widget' was not provided
Makefile:815: recipe for target 'bootstrap-emacs' failed
I'm puzzled at what to do about this. We keep all of our systems at
current patch levels, so there have certainly been many system updates
on Hurd between 24.3.94 (8-Oct-2014) and 24.5-rc1. I plan to go back
and try to build 24.3.94 again with the same build environment as
before.
In any event, I consider emacs-24.5-rc1 as yet another in long line of
outstanding successes in the quality and portability of GNU emacs
releases. Congratulations to the development team --- you've done a
great job in keeping this fantastic editor potentially available
virtually everywhere!
-------------------------------------------------------------------------------
- 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/ -
-------------------------------------------------------------------------------
next reply other threads:[~2015-03-28 15:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-28 15:19 Nelson H. F. Beebe [this message]
2015-03-28 17:48 ` bug#20218: emacs-24.5-rc1 build successes, and one failure Eli Zaretskii
[not found] <CMM.0.95.0.1427566289.beebe@psi.math.utah.edu>
2015-03-28 18:24 ` Eli Zaretskii
2015-03-28 18:32 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CMM.0.94.0.1427555966.beebe@psi.math.utah.edu \
--to=beebe@math.utah.edu \
--cc=20218@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.