| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
11.1 Specifying the System Type Specifying the system type 11.2 Getting the Canonical System Type Getting the canonical system type 11.3 Using the System Type What to do with the system type
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
config.guess.
If you mean to override the result of config.guess, use
`--build', not `--host', since the latter enables
cross-compilation. For historical reasons, passing `--host' also
changes the build type. Therefore, whenever you specify --host,
be sure to specify --build too. This will be fixed in the
future.
./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.
This section deliberately omits the description of the obsolete interface; see 15.6.3 Hosts and Cross-Compilation.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 `--build',
`--host', and `--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 4.4 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 `--build' was specified, then build is the
canonicalization of build_alias by 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 `--host' was specified, then host is the
canonicalization of host_alias by config.sub,
otherwise it defaults to build.
target, and its
three individual parts target_cpu, target_vendor, and
target_os.
If `--target' was specified, then target is the
canonicalization of target_alias by config.sub,
otherwise it defaults to host.
Note that there can be artifacts due to the backward compatibility code. See See section 15.6.3 Hosts and Cross-Compilation, for more.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 4.10 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 later in `configure.ac', use:
AC_CONFIG_LINKS(host.h:config/$machine.h
object.h:config/$obj_format.h)
|
Note that the above example uses $target because it's taken from
a tool which can be built on some architecture ($build), run on
another ($host), but yet handle data for a third architecture
($target). Such tools are usually part of a compiler suite, they
generate code for a specific $target.
However $target should be meaningless for most packages. If you
want to base a decision on the system where your program will be run,
make sure you use the $host variable, as in the following
excerpt:
case $host in
*-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
MUMBLE_INIT="mumble.ini"
;;
*)
MUMBLE_INIT=".mumbleinit"
;;
esac
AC_SUBST([MUMBLE_INIT])
|
You can also use the host system type to find cross-compilation tools.
See section 5.2.2 Generic Program and File Checks, for information about the AC_CHECK_TOOL
macro which does that.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |