The introduction of the previous section (the section called “Upgrading From Version 1”) perfectly suits this section...
Autoconf version 2.50 is mostly backward compatible with version 2.13. However, it introduces better ways to do some things, and doesn't support some of the ugly things in version 2.13. So, depending on how sophisticated your configure.ac files are, you might have to do some manual work in order to upgrade to version 2.50. This chapter points out some problems to watch for when upgrading. Also, perhaps your configure scripts could benefit from some of the new features in version 2.50; the changes are summarized in the file NEWS in the Autoconf distribution.
The most important changes are invisible to you: the implementation of most macros have completely changed. This allowed more factorization of the code, better error messages, a higher uniformity of the user's interface etc. Unfortunately, as a side effect, some construct which used to (miraculously) work might break starting with Autoconf 2.50. The most common culprit is bad quotation.
For instance, in the following example, the message is not properly quoted:
AC_INIT AC_CHECK_HEADERS(foo.h,, AC_MSG_ERROR(cannot find foo.h, bailing out)) AC_OUTPUT
Autoconf 2.13 simply ignores it:
$ autoconf-2.13; ./configure --silent creating cache ./config.cache configure: error: cannot find foo.h $
while Autoconf 2.50 will produce a broken configure:
$ autoconf-2.50; ./configure --silent configure: error: cannot find foo.h ./configure: exit: bad non-numeric arg `bailing' ./configure: exit: bad non-numeric arg `bailing' $
The message needs to be quoted, and the AC_MSG_ERROR invocation too!
AC_INIT AC_CHECK_HEADERS(foo.h,, [AC_MSG_ERROR([cannot find foo.h, bailing out])]) AC_OUTPUT
Many many (and many more) Autoconf macros were lacking proper quotation, including no less than... AC_DEFUN itself!
$ cat configure.in AC_DEFUN([AC_PROG_INSTALL], [# My own much better version ]) AC_INIT AC_PROG_INSTALL AC_OUTPUT $ autoconf-2.13 autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_FD_MSG ***BUG in Autoconf--please report*** AC_EPI configure.in:1:AC_DEFUN([AC_PROG_INSTALL], configure.in:5:AC_PROG_INSTALL $ autoconf-2.50 $
Because Autoconf has been dormant for years, Automake provided Autoconf-like macros for a while. Autoconf 2.50 now provides better versions of these macros, integrated in the AC_ namespace, instead of AM_. But in order to ease the upgrading via autoupdate, bindings to such AM_ macros are provided.
Unfortunately Automake did not quote the name of these macros! Therefore, when m4 finds something like AC_DEFUN(AM_TYPE_PTRDIFF_T, ...) in aclocal.m4, AM_TYPE_PTRDIFF_T is expanded, replaced with its Autoconf definition.
Fortunately Autoconf catches pre-AC_INIT expansions, and will complain, in its own words:
$ cat configure.in AC_INIT AM_TYPE_PTRDIFF_T $ aclocal-1.4 $ autoconf ./aclocal.m4:17: error: m4_defn: undefined macro: _m4_divert_diversion actypes.m4:289: AM_TYPE_PTRDIFF_T is expanded from... ./aclocal.m4:17: the top level $
Future versions of Automake will simply no longer define most of these macros, and will properly quote the names of the remaining macros. But you don't have to wait for it to happen to do the right thing right now: do not depend upon macros from Automake as it is simply not its job to provide macros (but the one it requires by itself):
$ cat configure.in AC_INIT AM_TYPE_PTRDIFF_T $ rm aclocal.m4 $ autoupdate autoupdate: `configure.in' is updated $ cat configure.in AC_INIT AC_CHECK_TYPES([ptrdiff_t]) $ aclocal-1.4 $ autoconf $
Based on the experience of compiler writers, and after long public debates, many aspects of the cross-compilation chain have changed:
the relationship between the build, host, and target architecture types,
the command line interface for specifying them to configure,
the variables defined in configure,
the enabling of cross-compilation mode.
The relationship between build, host, and target have been cleaned up: the chain of default is now simply: target defaults to host, host to build, and build to the result of config.guess. Nevertheless, in order to ease the transition from 2.13 to 2.50, the following transition scheme is implemented. Do not rely on it, as it will be completely disabled in a couple of releases (we cannot keep it, as it proves to cause more problems than to cure).
They all default to the result of running config.guess, unless you specify either -build or -host. In this case, the default becomes the system type you specified. If you specify both, and they're different, configure will enter cross compilation mode, so it won't run any tests that require execution.
Hint: if you mean to override the result of config.guess, prefer -build over -host. In the future, -host will not override the name of the build system type. Whenever you specify -host, be sure to specify -build too.
For backward compatibility, configure will accept a system type as an option by itself. Such an option will override the defaults for build, host and target system types. The following configure statement will configure a cross toolchain that will run on NetBSD/alpha but generate code for GNU Hurd/sparc, which is also the build platform.
./configure --host=alpha-netbsd sparc-gnu
In Autoconf, the variables build, host, and target had a different semantics before and after the invocation of AC_CANONICAL_BUILD etc. Now, the argument of -build is strictly copied into build_alias, and is left empty otherwise. After the AC_CANONICAL_BUILD, build is set to the canonicalized build type. To ease the transition, before, its contents is the same as that of build_alias. Do not rely on this broken feature.
For consistency with the backward compatibility scheme exposed above, when -host is specified by -build isn't, the build system will be assumed to be the same as -host, and build_alias will be set to that value. Eventually, this historically incorrect behavior will go away.
The former scheme to enable cross-compilation proved to cause more harm than good, in particular, it used to be triggered too easily, leaving regular end users puzzled in front of cryptic error messages. configure could even enter cross-compilation mode, only because the compiler was not functional. This is mainly because configure used to try to detect cross-compilation, instead of waiting for an explicit flag from the user.
Now, configure enters cross-compilation mode iff -host is passed.
That's the short documentation. To ease the transition between 2.13 and its successors, a more complicated scheme is implemented. Do not rely on the following, as it will be removed in a near future.
If you specify -host, but not -build, when configure performs the first compiler test it will try to run an executable produced by the compiler. If the execution fails, it will enter cross-compilation mode. This is fragile. Moreover, by the time the compiler test is performed, it may be too late to modify the build-system type: other tests may have already been performed. Therefore, whenever you specify -host, be sure to specify -build too.
./configure --build=i686-pc-linux-gnu --host=m68k-coff
will enter cross-compilation mode. The former interface, which consisted in setting the compiler to a cross-compiler without informing configure is obsolete. For instance, configure will fail if it can't run the code generated by the specified compiler if you configure as follows:
./configure CC=m68k-coff-gcc
Up to Autoconf 2.13, the replacement of functions was triggered via the variable LIBOBJS. Since Autoconf 2.50, the macro AC_LIBOBJ should be used instead (the section called “Generic Function Checks”). Starting at Autoconf 2.53, the use of LIBOBJS is an error.
This change is mandated by the unification of the GNU Build System components. In particular, the various fragile techniques used to parse a configure.ac are all replaced with the use of traces. As a consequence, any action must be traceable, which obsoletes critical variable assignments. Fortunately, LIBOBJS was the only problem.
At the time this documentation is written, Automake does not rely on traces yet, but this is planed for a near future. Nevertheless, to ease the transition, and to guarantee this future Automake release will be able to use Autoconf 2.53, using LIBOBJS directly will make autoconf fail. But note that the output, configure, is correct and fully functional: you have some delay to adjust your source.
There are two typical uses of LIBOBJS: asking for a replacement function, and adjusting LIBOBJS for Automake and/or Libtool.
As for function replacement, the fix is immediate: use AC_LIBOBJ. For instance:
LIBOBJS="$LIBOBJS fnmatch.o" LIBOBJS="$LIBOBJS malloc.$ac_objext"
should be replaced with:
AC_LIBOBJ([fnmatch]) AC_LIBOBJ([malloc])
When asked for automatic de-ANSI-fication, Automake needs LIBOBJS'ed filenames to have $U appended to the base names. Libtool requires the definition of LTLIBOBJS, which suffixes are mapped to .lo. Although Autoconf provides them with means to free the user to do that by herself, by the time of this writing, none do. Therefore, it is common to see configure.ac end with:
# This is necessary so that .o files in LIBOBJS are also built via # the ANSI2KNR-filtering rules. LIBOBJS=`echo "$LIBOBJS" | sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'` LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.o/\.lo/g'` AC_SUBST(LTLIBOBJS)
First, note that this code is wrong, because .o is not the only possible extension[21]! Because the token LIBOBJS is now forbidden, you will have to replace this snippet with:
# This is necessary so that .o files in LIBOBJS are also built via # the ANSI2KNR-filtering rules. LIB@t@OBJS=`echo "$LIB@t@OBJS" | sed 's,\.[[^.]]* ,$U,g;s,\.[[^.]]*$,$U,'` LTLIBOBJS=`echo "$LIB@t@OBJS" | sed 's,\.[[^.]]* ,.lo ,g;s,\.[[^.]]*$,.lo,'` AC_SUBST(LTLIBOBJS)
Unfortunately, autoupdate cannot help here, since... this is not a macro! Of course, first make sure your release of Automake and/or Libtool still requires these.