1. Changes in autoconf releases

1.1. autoconf 2.64

Release 2.64 of autoconf is an important release for developers working on old build systems based on it, because it is the release where the "present but cannot be compiled" warning switches behaviour.

Noteworthy changes in autoconf version 2.64

  • After eight years, AC_CHECK_HEADER takes as authoritative the result from the compiler, rather than the preprocessor, when the header present but cannot be compiled warning is issued. Refer to Section 4.2.2, “Headers Present But Cannot Be Compiled” for the details on how to fix the related issues.

  • The internal macro AH_CHECK_HEADERS has been removed; while this is an internal change that should not mean anything to properly-written autotools, this actually breaks packages using the KDE 3.x autotools-based build system, in particular the KDE_CHECK_HEADERS macro. To work with autoconf 2.64, KDE3-based software should replace the calls to the KDE-specific macro with equivalent calls to the proper, standard AC_CHECK_HEADERS macro, after properly setting up the language to C++ if needed.

1.2. autoconf 2.68

There aren't many specific changes in autoconf 2.68; but this version provides a new milestone in the package's history as it solves the (many) regressions that were introduced in the past two versions. For this reason, for the scope of this document, I'll be documenting the changes in 2.66, 2.67 and 2.68 as a single section.


You are encouraged to avoid as much as possible version 2.66 and 2.67 of autoconf. While they do include a few regression fixes against 2.65, they also introduce a much longer series of mistakes and regressions that were fixed only in 2.68.

Noteworthy changes in autoconf version 2.66 through 2.68

  • Macros designed to check for functionality (more than presence) of common library functions are being deprecated in favour of using the gnulib project framework. Eventually, alternative, slimmer macros might be looked up at the Autoconf archive. These macros are involved: AC_FUNC_ERROR_AT_LINE; AC_FUNC_LSTAT_FOLLOWS_SLASHED; AC_FUNC_MKTIME, AC_FUNC_STRTOD.

  • The If-Else family of macros (see Section 5, “Custom Autoconf Tests”) has gained a new safety switch to ensure that the source code being compiled is setting the expected defines that were discovered up to that point. If you call any of those macros with a literal text with the source code to work on, you'll be presented with a warning similar to the following:

    configure.ac:XX: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
    ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
    ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
    ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
    configure.ac:XX: the top level

    This means that calling macros such as AC_PREPROC_IFELSE or AC_LINK_IFELSE now requires the use of AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the source code to compile. As an alternative, the AC_LANG_DEFINES_PROVIDED macro can be used within the first parameter to stop autoconf from warning you about it.

    It is important to note that you need to ensure that the call to AC_LANG_SOURCE is quoted and not expanded, otherwise that will cause the warning to appear nonetheless. See the following code:

    dnl Old-style code (will issue a warning)
    AC_LINK_IFELSE([int main() { return 0; }],
      [some=thing], [some=other])
    dnl Wrongly updated code (will still issue a warning)
    AC_LINK_IFELSE(AC_LANG_SOURCE([int main() { return 0; }]),
      [some=thing], [some=other])
    dnl Correctly updated code
    AC_LINK_IFELSE([AC_LANG_SOURCE([int main() { return 0; }])],
      [some=thing], [some=other])