From 81c83618430a8f121ac4f6b909ac0029e3d6df70 Mon Sep 17 00:00:00 2001 From: Marko Lindqvist Date: Wed, 14 Apr 2021 14:01:34 +0300 Subject: [PATCH 50/50] Use AC_CHECK_HEADERS() when HAVE_xxx_H macro expected AC_CHECK_HEADERS() with two headers to check was recently changed to two separate AC_CHECK_HEADER() uses as one of them require special handling. What was missed, was that AC_CHECK_HEADER() does not define HAVE_xxx_H like AC_CHECK_HEADERS() does, leading to compilation failure. Replace those AC_CHECK_HEADER() uses with uses of single-parameter AC_CHECK_HEADERS() to have HAVE_xxx_H properly defined. This should fix OSX build. See osdn #42000 Signed-off-by: Marko Lindqvist --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index bd0cad4a67..00e7963963 100644 --- a/configure.ac +++ b/configure.ac @@ -1439,8 +1439,8 @@ AC_CHECK_FUNCS([getline _strcoll stricoll _stricoll strcasecoll]) AC_CHECK_FUNCS([backtrace setenv putenv]) dnl Possible random sources -AC_CHECK_HEADER([sys/random.h]) -AC_CHECK_HEADER([bcrypt.h], [bcrypt_h_found=yes], [bcrypt_h_found=no]) +AC_CHECK_HEADERS([sys/random.h]) +AC_CHECK_HEADERS([bcrypt.h], [bcrypt_h_found=yes], [bcrypt_h_found=no]) if test "x$bcrypt_h_found" = "xyes" ; then dnl Cygwin would find the symbol in library despite not finding the header, dnl leading to compile time error if we set HAVE_BCRYPTGENRANDOM -- 2.30.2