From: Paul Eggert <eggert@cs.ucla.edu>
To: 13872@debbugs.gnu.org
Subject: bug#13872: 24.3-rc1; TERM_HEADER multiply defined during 'configure'
Date: Mon, 04 Mar 2013 21:26:30 -0800 [thread overview]
Message-ID: <51358206.2040407@cs.ucla.edu> (raw)
Building Emacs 24.3-rc1 on Fedora 17 x86-64 generates a config.log with
lots of these diagnostics:
conftest.c:242:0: warning: "TERM_HEADER" redefined [enabled by default]
conftest.c:71:0: note: this is the location of the previous definition
The problem is that TERM_HEADER is put into conftest.c twice, with
disagreeing definitions:
#define TERM_HEADER "xterm.h"
...
#define TERM_HEADER "gtkutil.h"
On this platform it happens to work, but I worry that on other
platforms the C compiler will reject any such test program (as it is
entitled to do), which will cause later configuration decisions to
go wrong.
Here's a fix. This looks pretty safe.
=== modified file 'ChangeLog'
--- ChangeLog 2013-03-05 03:43:52 +0000
+++ ChangeLog 2013-03-05 05:21:41 +0000
@@ -1,3 +1,8 @@
+2013-03-05 Paul Eggert <eggert@cs.ucla.edu>
+
+ * configure.ac (TERM_HEADER): Remove duplicate definition
+ that can mess up 'configure' runs.
+
2013-03-05 Glenn Morris <rgm@gnu.org>
* Makefile.in (install-man): Ignore gzip exit status.
=== modified file 'configure.ac'
--- configure.ac 2013-03-05 03:53:34 +0000
+++ configure.ac 2013-03-05 04:50:24 +0000
@@ -1646,11 +1646,6 @@
;;
esac
-if test -n "${term_header}"; then
- AC_DEFINE_UNQUOTED(TERM_HEADER, "${term_header}",
- [Define to the header for the built-in window system.])
-fi
-
if test "$window_system" = none && test "X$with_x" != "Xno"; then
AC_CHECK_PROG(HAVE_XSERVER, X, true, false)
if test "$HAVE_XSERVER" = true ||
next reply other threads:[~2013-03-05 5:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-05 5:26 Paul Eggert [this message]
2013-03-05 8:28 ` bug#13872: 24.3-rc1; TERM_HEADER multiply defined during 'configure' Glenn Morris
2013-03-05 17:42 ` Eli Zaretskii
2013-03-05 13:40 ` Ken Brown
2013-03-05 14:56 ` Paul Eggert
2013-03-05 17:20 ` Glenn Morris
2013-03-05 17:26 ` Paul Eggert
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51358206.2040407@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=13872@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).