Go to the first, previous, next, last section, table of contents.
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.
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-vendor-os', where os can be
`system' or `kernel-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 infers 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(3):
They all default to the result of running config.guess, unless
you specify either @option{--build} or @option{--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
@option{--build} over @option{--host}. In the future, @option{--host} will
not override the name of the build system type. Also, if you specify
@option{--host}, but not @option{--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.
Note, however, that it won't guess the build-system type, since this may
require running test programs. 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, but 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
configure recognizes short aliases for many system types; for
example, `decstation' can be used instead of
`mips-dec-ultrix4.2'. configure runs a script called
config.sub to canonicalize system type aliases.
The following macros make the system type available to configure
scripts.
The variables `build_alias', `host_alias', and
`target_alias' are always exactly the arguments of @option{--build},
@option{--host}, and @option{--target}; in particular, they are left empty
if the user did not use them, even if the corresponding
AC_CANONICAL macro was run. Any configure script may use these
variables anywhere. These are the variables that should be used when in
interaction with the user.
If you need to recognize some special environments based on their system type, run the following macros to get canonical system names. These variables are not set before the macro call.
If you use these macros, you must distribute config.guess and
config.sub along with your source code. See section Outputting Files, for
information about the AC_CONFIG_AUX_DIR macro which you can use
to control in which directory configure looks for those scripts.
build, and its
three individual parts build_cpu, build_vendor, and
build_os.
If @option{--build} was specified, then build is the
canonicalization of build_alias by @command{config.sub},
otherwise it is determined by the shell script config.guess.
host, and its
three individual parts host_cpu, host_vendor, and
host_os.
If @option{--host} was specified, then host is the
canonicalization of host_alias by @command{config.sub},
otherwise it defaults to build.
For temporary backward-compatibility, when @option{--host} is specified by @option{--build} isn't, the build system will be assumed to be the same as @option{--host}, and `build_alias' will be set to that value. Eventually, this historically incorrect behavior will go away.
target, and its
three individual parts target_cpu, target_vendor, and
target_os.
If @option{--target} was specified, then target is the
canonicalization of target_alias by @command{config.sub},
otherwise it defaults to host.
How do you use a canonical system type? Usually, you use it in one or
more case statements in `configure.ac' to select
system-specific C files. Then, using AC_CONFIG_LINKS, link those
files which have names based on the system name, to generic names, such
as `host.h' or `target.c' (see section Creating Configuration Links). The
case statement patterns can use shell wild cards 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
and in `configure.ac', use:
AC_CONFIG_LINKS(host.h:config/$machine.h
object.h: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.