Manual Configuration

A few kinds of features can't be guessed automatically by running test programs. For example, the details of the object file format, or special options that need to be passed to the compiler or linker. You can check for such features using ad-hoc means, such as having configure check the output of the uname program, or looking for libraries that are unique to particular systems. However, Autoconf provides a uniform method for handling unguessable features.

Specifying the System Type

Like other GNU configure scripts, Autoconf-generated configure scripts can make decisions based on a canonical name for the system type, which has the form:

cpu-company-system

configure can usually guess the canonical name for the type of system it's running on. To do so it runs a script called config.guess, which derives the name using the uname command or symbols predefined by the C preprocessor.

Alternately, the user can specify the system type with command line arguments to configure. Doing so is necessary when cross-compiling. In the most complex case of cross-compiling, three system types are involved. The options to specify them are:

--build=build-type

the type of system on which the package is being configured and compiled (rarely needed);

--host=host-type

the type of system on which the package will run;

--target=target-type

the type of system for which any compiler tools in the package will produce code.

If the user gives configure a non-option argument, it is used as the default for the host, target, and build system types if the user does not specify them explicitly with options. The target and build types default to the host type if it is given and they are not. If you are cross-compiling, you still have to specify the names of the cross-tools you use, in particular the C compiler, on the configure command line, e.g.,

CC=m68k-coff-gcc configure --target=m68k-coff

configure recognizes short aliases for many system types; for example, `decstation' can be given on the command line instead of `mips-dec-ultrix4.2'. configure runs a script called config.sub to canonicalize system type aliases.

Getting the Canonical System Type

The following macros make the system type available to configure scripts. They run the shell script config.guess to determine any values for the host, target, and build types that they need and the user did not specify on the command line. They run config.sub to canonicalize any aliases the user gave. If you use these macros, you must distribute those two shell scripts along with your source code. See section Creating Output Files, for information about the AC_CONFIG_AUX_DIR macro which you can use to control which directory configure looks for those scripts in. If you do not use either of these macros, configure ignores any `--host', `--target', and `--build' options given to it.

Macro: AC_CANONICAL_SYSTEM

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

Macro: AC_CANONICAL_HOST

Perform only the subset of AC_CANONICAL_SYSTEM relevant to the host type. This is all that is needed for programs that are not part of a compiler toolchain.

Macro: AC_VALIDATE_CACHED_SYSTEM_TUPLE (cmd)

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

System Type Variables

After calling AC_CANONICAL_SYSTEM, the following output variables contain the system type information. After AC_CANONICAL_HOST, only the host variables below are set.

build, host, target

the canonical system names;

build_alias, host_alias, target_alias

the names the user specified, or the canonical names if config.guess was used;

build_cpu, build_vendor, build_os

host_cpu, host_vendor, host_os

target_cpu, target_vendor, target_os

the individual parts of the canonical names (for convenience).

Using the System Type

How do you use a canonical system type? Usually, you use it in one or more case statements in `configure.in' to select system-specific C files. Then link those files, which have names based on the system name, to generic names, such as `host.h' or `target.c'. The case statement patterns can use shell wildcards to group several cases together, like in this fragment:

case "$target" in
i386-*-mach* | i386-*-gnu*) obj_format=aout emulation=mach bfd_gas=yes ;;
i960-*-bout) obj_format=bout ;;
esac

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

Make AC_OUTPUT link each of the existing files source to the corresponding link name dest. Makes a symbolic link if possible, otherwise a hard link. The dest and source names should be relative to the top level source or build directory. This macro may be called multiple times.

For example, this call:

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

creates in the current directory `host.h', which is a link to `srcdir/config/${machine}.h', and `object.h', which is a link to `srcdir/config/${obj_format}.h'.

You can also use the host system type to find cross-compilation tools. See section Generic Program and File Checks, for information about the AC_CHECK_TOOL macro which does that.

Go to the first, previous, next, last section, table of contents.