When AC_USE_SYSTEM_EXTENSIONS is expanded from a macro that also expands AC_PROG_CC for the first time then expansion order is wrong:
$ cat configure.ac AC_INIT AC_DEFUN([FOO],[ AC_PROG_CC AC_USE_SYSTEM_EXTENSIONS ]) FOO AC_OUTPUT $ ./configure checking how to run the C preprocessor... /lib/cpp checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... no checking for sys/types.h... no checking for sys/stat.h... no checking for stdlib.h... no checking for string.h... no checking for memory.h... no checking for strings.h... no checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes configure: creating ./config.status The actual problem is the use of AC_INCLUDES_DEFAULT by AC_USE_SYSTEM_EXTENSIONS. It calls AC_REQUIRE([_AC_INCLUDES_DEFAULT_REQUIREMENTS]), which then pushes the expansion of _AC_INCLUDES_DEFAULT_REQUIREMENTS before the expansion of FOO and thus before AC_PROG_CC. This is also a problem with legacy configure scripts, since AC_AIX and AC_MINIX are now aliases of AC_USE_SYSTEM_EXTENSIONS. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
