unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Richard Copley <rcopley@gmail.com>, 37852@debbugs.gnu.org
Subject: bug#37852: Build failure on MSYS2 (undefined reference to _chk functions)
Date: Mon, 21 Oct 2019 17:40:12 -0700	[thread overview]
Message-ID: <cf5e6e9b-ba24-b667-fa4b-cd2f9971b6b6@cs.ucla.edu> (raw)
In-Reply-To: <CAPM58ojJU9FXHodR1Ad3y=5Rd4+e6ikkSb0HP4+7BS7VREyZoA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

> I think we should better disable GNULIB_PORTCHECK on MinGW (I can hardly
> imagine someone using that platform for those portability checks, and
> I'm not sure I understand why this gets defined by default on other
> platforms).

The intent of GNULIB_PORTCHECK is that it is enabled by developers who 
want some simple build-time portability tests. It isn't suitable for 
people who just want to build the software, as there are too many build 
failures and other false alarms that builders don't care about.

I installed the attached patch, to cause the problem to occur only if 
one configures explicitly with --enable-gcc-warnings. This should fix 
the problem that Richard reported. However, it won't fix the more 
general problem (which Richard should be able to reproduce via 
'./configure --enable-gcc-warnings ...').

Apparently MSYS2 changed recently, and this caused _FORTIFY_SOURCE 
builds to fail. See, for example:

https://github.com/msys2/MINGW-packages/issues/5803

I don't understand MSYS2 well enough to suggest fixes for Emacs, other 
than "don't configure with --enable-gcc-warnings and don't compile with 
_FORTIFY_SOURCE defined".

[-- Attachment #2: 0001-Portcheck-only-if-enable-gcc-warnings.patch --]
[-- Type: text/x-patch, Size: 1954 bytes --]

From 0ccd70a99b5cbd3cf7fea65c47a724846c578a43 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 21 Oct 2019 17:28:02 -0700
Subject: [PATCH] Portcheck only if --enable-gcc-warnings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Richard Copley (Bug#37852).
This patch causes the problem to not occur if one uses plain
‘configure’.  The problem can still occur if with ‘configure
--enable-gcc-warnings’, so a further fix may be needed.
* configure.ac (GNULIB_PORTCHECK, _FORTIFY_SOURCE):
Define these only with an explicit --enable-gcc-warnings.
---
 configure.ac | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 33d725c804..3b6a2a6d16 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1114,15 +1114,16 @@ AC_DEFUN
   fi
 
   AC_DEFINE([GCC_LINT], [1], [Define to 1 if --enable-gcc-warnings.])
-  AC_DEFINE([GNULIB_PORTCHECK], [1], [enable some gnulib portability checks])
-  AH_VERBATIM([GNULIB_PORTCHECK_FORTIFY_SOURCE],
-  [/* Enable compile-time and run-time bounds-checking, and some warnings,
-      without upsetting glibc 2.15+. */
-   #if (defined GNULIB_PORTCHECK && !defined _FORTIFY_SOURCE \
-        && defined __OPTIMIZE__ && __OPTIMIZE__)
-   # define _FORTIFY_SOURCE 2
-   #endif
-  ])
+  AS_IF([test $gl_gcc_warnings = yes],
+    [AC_DEFINE([GNULIB_PORTCHECK], [1], [enable some gnulib portability checks])
+     AH_VERBATIM([GNULIB_PORTCHECK_FORTIFY_SOURCE],
+     [/* Enable compile-time and run-time bounds-checking, and some warnings,
+	 without upsetting glibc 2.15+. */
+      #if (defined GNULIB_PORTCHECK && !defined _FORTIFY_SOURCE \
+	   && defined __OPTIMIZE__ && __OPTIMIZE__)
+      # define _FORTIFY_SOURCE 2
+      #endif
+     ])])
  ])
 
 # clang is picky about these regardless of whether
-- 
2.21.0


  parent reply	other threads:[~2019-10-22  0:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21 12:28 bug#37852: Build failure on MSYS2 (undefined reference to _chk functions) Richard Copley
2019-10-21 13:07 ` Eli Zaretskii
2019-10-21 13:17   ` Richard Copley
2019-10-21 13:31     ` Eli Zaretskii
2019-10-21 14:04       ` Richard Copley
2019-10-21 16:01         ` Eli Zaretskii
2019-10-21 16:05       ` Andy Moreton
2019-10-21 16:36         ` Eli Zaretskii
2019-10-21 16:55           ` Eli Zaretskii
2019-10-22  0:40 ` Paul Eggert [this message]
2019-10-22  2:37   ` Eli Zaretskii
2019-10-22 18:27     ` Paul Eggert
2019-10-22 18:51       ` Eli Zaretskii
2019-10-23 21:29         ` Richard Copley
2019-10-24 13:50           ` 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

  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=cf5e6e9b-ba24-b667-fa4b-cd2f9971b6b6@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=37852@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=rcopley@gmail.com \
    /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).