From dddcdb42c6d06cc9df331fdf2f3f87e4a11707f7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=89ric=20Hoffman?= Date: Wed, 29 Mar 2017 14:30:36 +0200 Subject: [PATCH] configure: work around a bug in AX_PROG_CC_FOR_BUILD... ... when building on Windows. From bug 780270, comment 18: I'm still having issue with Windows MinGW, but I have traced the issue with the autoconf itself, and the autoconf-archive script "ax_prog_cc_for_build.m4". I have written to the autoconf-archive mailing list. It seem that this script never worked as intended since a long time because the way it works, it pushdef a few elements, then it disable cross-compiling (for the following test), and invoke AC_PROG_CC (which in turn invoke the code that find and set the exe extention). Then it grab the BUILD_EXEEXT from that. This is neat and simple, but the issue is that the autoconf AC_PROG_CC macro only invoke the code that is responsible for finding the exe (and obj) extensions once (with m4_expand_once). So, the end-result is that in the resulting configure script, EXEEXT is properly evaluated, but when comes the time to evaluate BUILD_EXEEXT, no test is performed to actually find the exe (and obj) extension, even if the cross-compilation option changed (which is the case for the duration of this test). So, BUILD_EXEEXT will always end up blank (defined, but blank). --- configure.ac | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/configure.ac b/configure.ac index d0672d5847..1aa0e2dfa0 100644 --- a/configure.ac +++ b/configure.ac @@ -233,6 +233,11 @@ AS_IF([test "x$0" != "x./configure"], [ # Determine a C compiler to use AC_PROG_CC AX_PROG_CC_FOR_BUILD +# Works around a bug in AX_PROG_CC_FOR_BUILD for build with MinGW on +# Windows. See bug 780270, comment 18. +case "$build_os" in + cygwin*|mingw32*|mingw64*) BUILD_EXEEXT=.exe ;; +esac AM_PROG_CC_C_O # Determine a C++ compiler to use