On Sun, Feb 28, 2021 at 1:33 AM Werner LEMBERG <w...@gnu.org> wrote: > [autoconf 6d38e9fa2b] > [clang 9.0.1] > [https://github.com/libarchive/libarchive.git] > > fails as below. ... > checking whether C compiler accepts -Wall... yes > checking whether C compiler accepts -Wformat... yes > checking whether C compiler accepts -Wformat-security... yes > checking for an ANSI C-conforming const... yes > checking for uid_t in sys/types.h... no
Something has already gone wrong at this point. The corresponding bit of config.log reads configure:17375: clang -c -g -O2 -Wall -Wformat -Wformat-security -I/usr/include/libxml2 conftest.c >&5 configure:17375: $? = 0 configure:17383: result: yes configure:17393: checking for uid_t in sys/types.h ./configure: line 17404: -I/usr/include/libxml2: No such file or directory configure:17414: result: no It tried to run `-I/usr/include/libxml2` as an executable. As a side effect of this bug, junk gets written to confdefs.h that causes all subsequent tests to fail, including the one that made configure ultimately give up. The problematic check is implemented in la_uid_t.m4 (https://github.com/libarchive/libarchive/blob/master/build/autoconf/la_uid_t.m4). It should be using AC_CHECK_TYPE instead of AC_EGREP_HEADER, and it's underquoted, but I don't see anything that would have caused this kind of catastrophic failure. I suspect this is a case of improper use of macros with prerequisites, earlier in the script somewhere. Quoting 2.70's NEWS: *** Many macros no longer AC_REQUIRE as many other macros as they used to. This can expose several classes of latent bugs. These are the ones we know about: - Make sure to explicitly invoke all of the macros that set result variables used later in the configure script, or in generated Makefiles. - Autoconf macros that use AC_REQUIRE are not safe to use in shell control-flow constructs that appear outside of macros defined by AC_DEFUN. Use AS_IF, AS_CASE, etc. instead. (See the “Prerequisite Macros” section of the manual for details.) The set of macros that use AC_REQUIRE internally may change from release to release. The only macros that are guaranteed *not* to use AC_REQUIRE are the macros for acting on the results of a test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc. - AC_REQUIRE cannot be applied to macros that need to be used with arguments. Instead, invoke the macro normally, with its arguments. zw