15. Obsolete Constructs

Autoconf changes, and throughout the years some constructs are obsoleted. Most of the changes involve the macros, but the tools themselves, or even some concepts, are now considered obsolete.

You may completely skip this chapter if you are new to Autoconf, its intention is mainly to help maintainers updating their packages by understanding how to move to more modern constructs.

15.1 Obsolete `config.status' Invocation		Different calling convention
15.2 `acconfig.h'		Additional entries in `config.h.in'
15.3 Using autoupdate to Modernize `configure.ac'		Automatic update of `configure.ac'
15.4 Obsolete Macros		Backward compatibility macros
15.5 Upgrading From Version 1		Tips for upgrading your files
15.6 Upgrading From Version 2.13		Some fresher tips

15.1 Obsolete `config.status' Invocation

`config.status' now supports arguments to specify the files to instantiate, see 14. Recreating a Configuration, for more details. Before, environment variables had to be used.

Variable: CONFIG_COMMANDS

The tags of the commands to execute. The default is the arguments given to AC_OUTPUT and AC_CONFIG_COMMANDS in `configure.ac'.

Variable: CONFIG_FILES

The files in which to perform `@variable@' substitutions. The default is the arguments given to AC_OUTPUT and AC_CONFIG_FILES in `configure.ac'.

Variable: CONFIG_HEADERS

The files in which to substitute C #define statements. The default is the arguments given to AC_CONFIG_HEADERS; if that macro was not called, `config.status' ignores this variable.

Variable: CONFIG_LINKS

The symbolic links to establish. The default is the arguments given to AC_CONFIG_LINKS; if that macro was not called, `config.status' ignores this variable.

In 14. Recreating a Configuration, using this old interface, the example would be:

config.h: stamp-h stamp-h: config.h.in config.status CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_FILES= \ CONFIG_HEADERS=config.h ./config.status echo > stamp-h Makefile: Makefile.in config.status CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \ CONFIG_FILES=Makefile ./config.status

(If `configure.ac' does not call AC_CONFIG_HEADERS, there is no need to set CONFIG_HEADERS in the make rules, equally for CONFIG_COMMANDS etc.)

15.2 `acconfig.h'

In order to produce `config.h.in', autoheader needs to build or to find templates for each symbol. Modern releases of Autoconf use AH_VERBATIM and AH_TEMPLATE (see section 4.8.3 Autoheader Macros), but in older releases a file, `acconfig.h', contained the list of needed templates. autoheader copies comments and #define and #undef statements from `acconfig.h' in the current directory, if present. This file used to be mandatory if you AC_DEFINE any additional symbols.

Modern releases of Autoconf also provide AH_TOP and AH_BOTTOM if you need to prepend/append some information to `config.h.in'. Ancient versions of Autoconf had a similar feature: if `./acconfig.h' contains the string `@TOP@', autoheader copies the lines before the line containing `@TOP@' into the top of the file that it generates. Similarly, if `./acconfig.h' contains the string `@BOTTOM@', autoheader copies the lines after that line to the end of the file it generates. Either or both of those strings may be omitted. An even older alternate way to produce the same effect in jurasik versions of Autoconf is to create the files `file.top' (typically `config.h.top') and/or `file.bot' in the current directory. If they exist, autoheader copies them to the beginning and end, respectively, of its output.

In former versions of Autoconf, the files used in preparing a software package for distribution were:

configure.ac --. .------> autoconf* -----> configure +---+ [aclocal.m4] --+ `---. [acsite.m4] ---' | +--> [autoheader*] -> [config.h.in] [acconfig.h] ----. | +-----' [config.h.top] --+ [config.h.bot] --'

Use only the AH_ macros, `configure.ac' should be self-contained, and should not depend upon `acconfig.h' etc.

15.3 Using autoupdate to Modernize `configure.ac'

The autoupdate program updates a `configure.ac' file that calls Autoconf macros by their old names to use the current macro names. In version 2 of Autoconf, most of the macros were renamed to use a more uniform and descriptive naming scheme. See section 9.2 Macro Names, for a description of the new scheme. Although the old names still work (see section 15.4 Obsolete Macros, for a list of the old macros and the corresponding new names), you can make your `configure.ac' files more readable and make it easier to use the current Autoconf documentation if you update them to use the new macro names.

If given no arguments, autoupdate updates `configure.ac', backing up the original version with the suffix `~' (or the value of the environment variable SIMPLE_BACKUP_SUFFIX, if that is set). If you give autoupdate an argument, it reads that file instead of `configure.ac' and writes the updated file to the standard output.

autoupdate accepts the following options:

`--help'

`-h'

Print a summary of the command line options and exit.

`--version'

`-V'

Print the version number of Autoconf and exit.

`--verbose'

`-v'

Report processing steps.

`--debug'

`-d'

Don't remove the temporary files.

`--force'

`-f'

Force the update even if the file has not changed. Disregard the cache.

`--include=dir'

`-I dir'

Also look for input files in dir. Multiple invocations accumulate. Directories are browsed from last to first.

15.4 Obsolete Macros

Several macros are obsoleted in Autoconf, for various reasons (typically they failed to quote properly, couldn't be extended for more recent issues etc.). They are still supported, but deprecated: their use should be avoided.

During the jump from Autoconf version 1 to version 2, most of the macros were renamed to use a more uniform and descriptive naming scheme, but their signature did not change. See section 9.2 Macro Names, for a description of the new naming scheme. Below, there is just the mapping from old names to new names for these macros, the reader is invited to refer to the definition of the new macro for the signature and the description.

Macro: AC_ALLOCA

AC_FUNC_ALLOCA

Macro: AC_ARG_ARRAY

removed because of limited usefulness

Macro: AC_C_CROSS

This macro is obsolete; it does nothing.

Macro: AC_CANONICAL_SYSTEM

Determine the system type and set output variables to the names of the canonical system types. See section 11.2 Getting the Canonical System Type, for details about the variables this macro sets.

The user is encouraged to use either AC_CANONICAL_BUILD, or AC_CANONICAL_HOST, or AC_CANONICAL_TARGET, depending on the needs. Using AC_CANONICAL_TARGET is enough to run the two other macros.

Macro: AC_CHAR_UNSIGNED

AC_C_CHAR_UNSIGNED

Macro: AC_CHECK_TYPE (type, default)

Autoconf, up to 2.13, used to provide this version of AC_CHECK_TYPE, deprecated because of its flaws. Firstly, although it is a member of the CHECK clan, singular sub-family, it does more than just checking. Second, missing types are not typedef'd, they are #define'd, which can lead to incompatible code in the case of pointer types.

This use of AC_CHECK_TYPE is obsolete and discouraged, see 5.9.2 Generic Type Checks, for the description of the current macro.

If the type type is not defined, define it to be the C (or C++) builtin type default; e.g., `short' or `unsigned'.

This macro is equivalent to:

AC_CHECK_TYPE([type], [AC_DEFINE([type], [default], [Define to `default' if <sys/types.h> does not define.])])

In order to keep backward compatibility, the two versions of AC_CHECK_TYPE are implemented, selected by a simple heuristics:

1. If there are three or four arguments, the modern version is used.

2. If the second argument appears to be a C or C++ type, then the obsolete version is used. This happens if the argument is a C or C++ builtin type or a C identifier ending in `_t', optionally followed by one of `[(* ' and then by a string of zero or more characters taken from the set `[]()* _a-zA-Z0-9'.

3. If the second argument is spelled with the alphabet of valid C and C++ types, the user is warned and the modern version is used.

4. Otherwise, the modern version is used.

You are encouraged either to use a valid builtin type, or to use the equivalent modern code (see above), or better yet, to use AC_CHECK_TYPES together with

#if !HAVE_LOFF_T typedef loff_t off_t; #endif

Macro: AC_CHECKING (feature-description)

Same as `AC_MSG_NOTICE([checking feature-description...]'.

Macro: AC_COMPILE_CHECK (echo-text, includes, function-body, action-if-found, [action-if-not-found])

This is an obsolete version of AC_TRY_LINK (see section 6.3 Examining Libraries), with the addition that it prints `checking for echo-text' to the standard output first, if echo-text is non-empty. Use AC_MSG_CHECKING and AC_MSG_RESULT instead to print messages (see section 7.4 Printing Messages).

Macro: AC_CONST

AC_C_CONST

Macro: AC_CROSS_CHECK

Same as AC_C_CROSS, which is obsolete too, and does nothing :-).

Macro: AC_CYGWIN

Check for the Cygwin environment in which case the shell variable CYGWIN is set to `yes'. Don't use this macro, the dignified means to check the nature of the host is using AC_CANONICAL_HOST. As a matter of fact this macro is defined as:

AC_REQUIRE([AC_CANONICAL_HOST])[]dnl case $host_os in *cygwin* ) CYGWIN=yes;; * ) CYGWIN=no;; esac

Beware that the variable CYGWIN has a very special meaning when running CygWin32, and should not be changed. That's yet another reason not to use this macro.

Macro: AC_DECL_YYTEXT

Does nothing, now integrated in AC_PROG_LEX.

Macro: AC_DIR_HEADER

Like calling AC_FUNC_CLOSEDIR_VOID andAC_HEADER_DIRENT, but defines a different set of C preprocessor macros to indicate which header file is found:

Header	Old Symbol	New Symbol
`dirent.h'	DIRENT	HAVE_DIRENT_H
`sys/ndir.h'	SYSNDIR	HAVE_SYS_NDIR_H
`sys/dir.h'	SYSDIR	HAVE_SYS_DIR_H
`ndir.h'	NDIR	HAVE_NDIR_H

Macro: AC_DYNIX_SEQ

If on Dynix/PTX (Sequent UNIX), add `-lseq' to output variable LIBS. This macro used to be defined as

AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS")

now it is just AC_FUNC_GETMNTENT.

Macro: AC_EXEEXT

Defined the output variable EXEEXT based on the output of the compiler, which is now done automatically. Typically set to empty string if Unix and `.exe' if Win32 or OS/2.

Macro: AC_EMXOS2

Similar to AC_CYGWIN but checks for the EMX environment on OS/2 and sets EMXOS2.

Macro: AC_ERROR

AC_MSG_ERROR

Macro: AC_FIND_X

AC_PATH_X

Macro: AC_FIND_XTRA

AC_PATH_XTRA

Macro: AC_FUNC_CHECK

AC_CHECK_FUNC

Macro: AC_FUNC_WAIT3

If wait3 is found and fills in the contents of its third argument (a `struct rusage *'), which HP-UX does not do, define HAVE_WAIT3.

These days portable programs should use waitpid, not wait3, as wait3 is being removed from the Open Group standards, and will not appear in the next revision of POSIX.

Macro: AC_GCC_TRADITIONAL

AC_PROG_GCC_TRADITIONAL

Macro: AC_GETGROUPS_T

AC_TYPE_GETGROUPS

Macro: AC_GETLOADAVG

AC_FUNC_GETLOADAVG

Macro: AC_HAVE_FUNCS

AC_CHECK_FUNCS

Macro: AC_HAVE_HEADERS

AC_CHECK_HEADERS

Macro: AC_HAVE_LIBRARY (library, [action-if-found], [action-if-not-found], [other-libraries])

This macro is equivalent to calling AC_CHECK_LIB with a function argument of main. In addition, library can be written as any of `foo', `-lfoo', or `libfoo.a'. In all of those cases, the compiler is passed `-lfoo'. However, library cannot be a shell variable; it must be a literal name.

Macro: AC_HAVE_POUNDBANG

AC_SYS_INTERPRETER (different calling convention)

Macro: AC_HEADER_CHECK

AC_CHECK_HEADER

Macro: AC_HEADER_EGREP

AC_EGREP_HEADER

Macro: AC_INIT (unique-file-in-source-dir)

Formerly AC_INIT used to have a single argument, and was equivalent to:

AC_INIT AC_CONFIG_SRCDIR(unique-file-in-source-dir)

Macro: AC_INLINE

AC_C_INLINE

Macro: AC_INT_16_BITS

If the C type int is 16 bits wide, define INT_16_BITS. Use `AC_CHECK_SIZEOF(int)' instead.

Macro: AC_IRIX_SUN

If on IRIX (Silicon Graphics UNIX), add `-lsun' to output LIBS. If you were using it to get getmntent, use AC_FUNC_GETMNTENT instead. If you used it for the NIS versions of the password and group functions, use `AC_CHECK_LIB(sun, getpwnam)'. Up to Autoconf 2.13, it used to be

AC_CHECK_LIB(sun, getmntent, LIBS="-lsun $LIBS")

now it is defined as

AC_FUNC_GETMNTENT AC_CHECK_LIB(sun, getpwnam)

Macro: AC_LANG_C

Same as `AC_LANG(C)'.

Macro: AC_LANG_CPLUSPLUS

Same as `AC_LANG(C++)'.

Macro: AC_LANG_FORTRAN77

Same as `AC_LANG(Fortran 77)'.

Macro: AC_LANG_RESTORE

Select the language that is saved on the top of the stack, as set by AC_LANG_SAVE, remove it from the stack, and call AC_LANG(language).

Macro: AC_LANG_SAVE

Remember the current language (as set by AC_LANG) on a stack. The current language does not change. AC_LANG_PUSH is preferred.

Macro: AC_LINK_FILES (source..., dest...)

This is an obsolete version of AC_CONFIG_LINKS. An updated version of:

AC_LINK_FILES(config/$machine.h config/$obj_format.h, host.h object.h)

is:

AC_CONFIG_LINKS(host.h:config/$machine.h object.h:config/$obj_format.h)

Macro: AC_LN_S

AC_PROG_LN_S

Macro: AC_LONG_64_BITS

Define LONG_64_BITS if the C type long int is 64 bits wide. Use the generic macro `AC_CHECK_SIZEOF([long int])' instead.

Macro: AC_LONG_DOUBLE

AC_C_LONG_DOUBLE

Macro: AC_LONG_FILE_NAMES

AC_SYS_LONG_FILE_NAMES

Macro: AC_MAJOR_HEADER

AC_HEADER_MAJOR

Macro: AC_MEMORY_H

Used to define NEED_MEMORY_H if the mem functions were defined in `memory.h'. Today it is equivalent to `AC_CHECK_HEADERS(memory.h)'. Adjust your code to depend upon HAVE_MEMORY_H, not NEED_MEMORY_H, see See section 5.1.1 Standard Symbols.

Macro: AC_MINGW32

Similar to AC_CYGWIN but checks for the MingW32 compiler environment and sets MINGW32.

Macro: AC_MINUS_C_MINUS_O

AC_PROG_CC_C_O

Macro: AC_MMAP

AC_FUNC_MMAP

Macro: AC_MODE_T

AC_TYPE_MODE_T

Macro: AC_OBJEXT

Defined the output variable OBJEXT based on the output of the compiler, after .c files have been excluded. Typically set to `o' if Unix, `obj' if Win32. Now the compiler checking macros handle this automatically.

Macro: AC_OBSOLETE (this-macro-name, [suggestion])

Make m4 print a message to the standard error output warning that this-macro-name is obsolete, and giving the file and line number where it was called. this-macro-name should be the name of the macro that is calling AC_OBSOLETE. If suggestion is given, it is printed at the end of the warning message; for example, it can be a suggestion for what to use instead of this-macro-name.

For instance

AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl

You are encouraged to use AU_DEFUN instead, since it gives better services to the user.

Macro: AC_OFF_T

AC_TYPE_OFF_T

Macro: AC_OUTPUT ([file]..., [extra-cmds], [init-cmds])

The use of AC_OUTPUT with argument is deprecated, this obsoleted interface is equivalent to:

AC_CONFIG_FILES(file...) AC_CONFIG_COMMANDS([default], extra-cmds, init-cmds) AC_OUTPUT

Macro: AC_OUTPUT_COMMANDS (extra-cmds, [init-cmds])

Specify additional shell commands to run at the end of `config.status', and shell commands to initialize any variables from configure. This macro may be called multiple times. It is obsolete, replaced by AC_CONFIG_COMMANDS.

Here is an unrealistic example:

fubar=27 AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], [fubar=$fubar]) AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit])

Aside from the fact that AC_CONFIG_COMMANDS requires an additional key, an important difference is that AC_OUTPUT_COMMANDS is quoting its arguments twice, while AC_CONFIG_COMMANDS. This means that AC_CONFIG_COMMANDS can safely be given macro calls as arguments:

AC_CONFIG_COMMANDS(foo, [my_FOO()])

conversely, where one level of quoting was enough for literal strings with AC_OUTPUT_COMMANDS, you need two with AC_CONFIG_COMMANDS. The following lines are equivalent:

AC_OUTPUT_COMMANDS([echo "Square brackets: []"]) AC_CONFIG_COMMANDS([default], [[echo "Square brackets: []"]])

Macro: AC_PID_T

AC_TYPE_PID_T

Macro: AC_PREFIX

AC_PREFIX_PROGRAM

Macro: AC_PROGRAMS_CHECK

AC_CHECK_PROGS

Macro: AC_PROGRAMS_PATH

AC_PATH_PROGS

Macro: AC_PROGRAM_CHECK

AC_CHECK_PROG

Macro: AC_PROGRAM_EGREP

AC_EGREP_CPP

Macro: AC_PROGRAM_PATH

AC_PATH_PROG

Macro: AC_REMOTE_TAPE

removed because of limited usefulness

Macro: AC_RESTARTABLE_SYSCALLS

AC_SYS_RESTARTABLE_SYSCALLS

Macro: AC_RETSIGTYPE

AC_TYPE_SIGNAL

Macro: AC_RSH

Removed because of limited usefulness.

Macro: AC_SCO_INTL

If on SCO UNIX, add `-lintl' to output variable LIBS. This macro used to

AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS")

now it just calls AC_FUNC_STRFTIME instead.

Macro: AC_SETVBUF_REVERSED

AC_FUNC_SETVBUF_REVERSED

Macro: AC_SET_MAKE

AC_PROG_MAKE_SET

Macro: AC_SIZEOF_TYPE

AC_CHECK_SIZEOF

Macro: AC_SIZE_T

AC_TYPE_SIZE_T

Macro: AC_STAT_MACROS_BROKEN

AC_HEADER_STAT

Macro: AC_STDC_HEADERS

AC_HEADER_STDC

Macro: AC_STRCOLL

AC_FUNC_STRCOLL

Macro: AC_ST_BLKSIZE

AC_STRUCT_ST_BLKSIZE

Macro: AC_ST_BLOCKS

AC_STRUCT_ST_BLOCKS

Macro: AC_ST_RDEV

AC_STRUCT_ST_RDEV

Macro: AC_SYS_RESTARTABLE_SYSCALLS

If the system automatically restarts a system call that is interrupted by a signal, define HAVE_RESTARTABLE_SYSCALLS. This macro does not check if system calls are restarted in general--it tests whether a signal handler installed with signal (but not sigaction) causes system calls to be restarted. It does not test if system calls can be restarted when interrupted by signals that have no handler.

These days portable programs should use sigaction with SA_RESTART if they want restartable system calls. They should not rely on HAVE_RESTARTABLE_SYSCALLS, since nowadays whether a system call is restartable is a dynamic issue, not a configuration-time issue.

Macro: AC_SYS_SIGLIST_DECLARED

AC_DECL_SYS_SIGLIST

Macro: AC_TEST_CPP

AC_TRY_CPP

Macro: AC_TEST_PROGRAM

AC_TRY_RUN

Macro: AC_TIMEZONE

AC_STRUCT_TIMEZONE

Macro: AC_TIME_WITH_SYS_TIME

AC_HEADER_TIME

Macro: AC_UID_T

AC_TYPE_UID_T

Macro: AC_UNISTD_H

Same as `AC_CHECK_HEADERS(unistd.h)'.

Macro: AC_USG

Define USG if the BSD string functions are defined in `strings.h'. You should no longer depend upon USG, but on HAVE_STRING_H, see See section 5.1.1 Standard Symbols.

Macro: AC_UTIME_NULL

AC_FUNC_UTIME_NULL

Macro: AC_VALIDATE_CACHED_SYSTEM_TUPLE ([cmd])

If the cache file is inconsistent with the current host, target and build system types, it used to execute cmd or print a default error message.

This is now handled by default.

Macro: AC_VERBOSE (result-description)

AC_MSG_RESULT.

Macro: AC_VFORK

AC_FUNC_VFORK

Macro: AC_VPRINTF

AC_FUNC_VPRINTF

Macro: AC_WAIT3

AC_FUNC_WAIT3

Macro: AC_WARN

AC_MSG_WARN

Macro: AC_WORDS_BIGENDIAN

AC_C_BIGENDIAN

Macro: AC_XENIX_DIR

This macro used to add `-lx' to output variable LIBS if on Xenix. Also, if `dirent.h' is being checked for, added `-ldir' to LIBS. Now it is merely an alias of AC_HEADER_DIRENT instead, plus some code to detect whether running XENIX on which you should not depend:

AC_MSG_CHECKING([for Xenix]) AC_EGREP_CPP(yes, [#if defined M_XENIX && !defined M_UNIX yes #endif], [AC_MSG_RESULT([yes]); XENIX=yes], [AC_MSG_RESULT([no]); XENIX=])

Macro: AC_YYTEXT_POINTER

AC_DECL_YYTEXT

15.5 Upgrading From Version 1

Autoconf version 2 is mostly backward compatible with version 1. However, it introduces better ways to do some things, and doesn't support some of the ugly things in version 1. 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. 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; the changes are summarized in the file `NEWS' in the Autoconf distribution.

15.5.1 Changed File Names		Files you might rename
15.5.2 Changed Makefiles		New things to put in `Makefile.in'
15.5.3 Changed Macros		Macro calls you might replace
15.5.4 Changed Results		Changes in how to check test results
15.5.5 Changed Macro Writing		Better ways to write your own macros

15.5.1 Changed File Names

If you have an `aclocal.m4' installed with Autoconf (as opposed to in a particular package's source directory), you must rename it to `acsite.m4'. See section 3.4 Using autoconf to Create configure.

If you distribute `install.sh' with your package, rename it to `install-sh' so make builtin rules won't inadvertently create a file called `install' from it. AC_PROG_INSTALL looks for the script under both names, but it is best to use the new name.

If you were using `config.h.top', `config.h.bot', or `acconfig.h', you still can, but you will have less clutter if you use the AH_ macros. See section 4.8.3 Autoheader Macros.

15.5.2 Changed Makefiles

Add `@CFLAGS@', `@CPPFLAGS@', and `@LDFLAGS@' in your `Makefile.in' files, so they can take advantage of the values of those variables in the environment when configure is run. Doing this isn't necessary, but it's a convenience for users.

Also add `@configure_input@' in a comment to each input file for AC_OUTPUT, so that the output files will contain a comment saying they were produced by configure. Automatically selecting the right comment syntax for all the kinds of files that people call AC_OUTPUT on became too much work.

Add `config.log' and `config.cache' to the list of files you remove in distclean targets.

If you have the following in `Makefile.in':

prefix = /usr/local exec_prefix = $(prefix)

you must change it to:

prefix = @prefix@ exec_prefix = @exec_prefix@

The old behavior of replacing those variables without `@' characters around them has been removed.

15.5.3 Changed Macros

Many of the macros were renamed in Autoconf version 2. You can still use the old names, but the new ones are clearer, and it's easier to find the documentation for them. See section 15.4 Obsolete Macros, for a table showing the new names for the old macros. Use the autoupdate program to convert your `configure.ac' to using the new macro names. See section 15.3 Using autoupdate to Modernize `configure.ac'.

Some macros have been superseded by similar ones that do the job better, but are not call-compatible. If you get warnings about calling obsolete macros while running autoconf, you may safely ignore them, but your configure script will generally work better if you follow the advice it prints about what to replace the obsolete macros with. In particular, the mechanism for reporting the results of tests has changed. If you were using echo or AC_VERBOSE (perhaps via AC_COMPILE_CHECK), your configure script's output will look better if you switch to AC_MSG_CHECKING and AC_MSG_RESULT. See section 7.4 Printing Messages. Those macros work best in conjunction with cache variables. See section 7.3 Caching Results.

15.5.4 Changed Results

If you were checking the results of previous tests by examining the shell variable DEFS, you need to switch to checking the values of the cache variables for those tests. DEFS no longer exists while configure is running; it is only created when generating output files. This difference from version 1 is because properly quoting the contents of that variable turned out to be too cumbersome and inefficient to do every time AC_DEFINE is called. See section 7.3.1 Cache Variable Names.

For example, here is a `configure.ac' fragment written for Autoconf version 1:

AC_HAVE_FUNCS(syslog) case "$DEFS" in *-DHAVE_SYSLOG*) ;; *) # syslog is not in the default libraries. See if it's in some other. saved_LIBS="$LIBS" for lib in bsd socket inet; do AC_CHECKING(for syslog in -l$lib) LIBS="$saved_LIBS -l$lib" AC_HAVE_FUNCS(syslog) case "$DEFS" in *-DHAVE_SYSLOG*) break ;; *) ;; esac LIBS="$saved_LIBS" done ;; esac

Here is a way to write it for version 2:

AC_CHECK_FUNCS(syslog) if test $ac_cv_func_syslog = no; then # syslog is not in the default libraries. See if it's in some other. for lib in bsd socket inet; do AC_CHECK_LIB($lib, syslog, [AC_DEFINE(HAVE_SYSLOG) LIBS="$LIBS -l$lib"; break]) done fi

If you were working around bugs in AC_DEFINE_UNQUOTED by adding backslashes before quotes, you need to remove them. It now works predictably, and does not treat quotes (except back quotes) specially. See section 7.2 Setting Output Variables.

All of the boolean shell variables set by Autoconf macros now use `yes' for the true value. Most of them use `no' for false, though for backward compatibility some use the empty string instead. If you were relying on a shell variable being set to something like 1 or `t' for true, you need to change your tests.

15.5.5 Changed Macro Writing

When defining your own macros, you should now use AC_DEFUN instead of define. AC_DEFUN automatically calls AC_PROVIDE and ensures that macros called via AC_REQUIRE do not interrupt other macros, to prevent nested `checking...' messages on the screen. There's no actual harm in continuing to use the older way, but it's less convenient and attractive. See section 9.1 Macro Definitions.

You probably looked at the macros that came with Autoconf as a guide for how to do things. It would be a good idea to take a look at the new versions of them, as the style is somewhat improved and they take advantage of some new features.

If you were doing tricky things with undocumented Autoconf internals (macros, variables, diversions), check whether you need to change anything to account for changes that have been made. Perhaps you can even use an officially supported technique in version 2 instead of kludging. Or perhaps not.

To speed up your locally written feature tests, add caching to them. See whether any of your tests are of general enough usefulness to encapsulate into macros that you can share.

15.6 Upgrading From Version 2.13

The introduction of the previous section (see section 15.5 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.

15.6.1 Changed Quotation		Broken code which used to work
15.6.2 New Macros		Interaction with foreign macros
15.6.3 Hosts and Cross-Compilation		Bugward compatibility kludges
15.6.4 AC_LIBOBJ vs. LIBOBJS		LIBOBJS is a forbidden token

15.6.1 Changed Quotation

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 $

15.6.2 New Macros

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 $

15.6.3 Hosts and Cross-Compilation

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

15.6.4 AC_LIBOBJ vs. LIBOBJS

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 (see section 5.5.3 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(4)! 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.