[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14. 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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.1 Specifying target triplets

Autoconf-generated configure scripts can make decisions based on a canonical name for the system type, or target triplet, 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 (see section Specifying the System Type. 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. It defaults to the result of running config.guess.

`--host=host-type'

the type of system on which the package runs. By default it is the same as the build machine. Specifying it enables the cross-compilation mode.

`--target=target-type'

the type of system for which any compiler tools in the package produce code (rarely needed). By default, it is the same as host.

If you mean to override the result of config.guess, use `--build', not `--host', since the latter enables cross-compilation. For historical reasons, whenever you specify `--host', be sure to specify `--build' too; this will be fixed in the future. So, to enter cross-compilation mode, use a command like this

 
./configure --build=i686-pc-linux-gnu --host=m68k-coff

Note that if you do not specify `--host', configure fails if it can't run the code generated by the specified compiler. For example, configuring as follows fails:

 
./configure CC=m68k-coff-gcc

When cross-compiling, configure will warn about any tools (compilers, linkers, assemblers) whose name is not prefixed with the host type. This is an aid to users performing cross-compilation. Continuing the example above, if a cross-compiler named cc is used with a native pkg-config, then libraries found by pkg-config will likely cause subtle build failures; but using the names m68k-coff-cc and m68k-coff-pkg-config avoids any confusion. Avoiding the warning is as simple as creating the correct symlinks naming the cross tools.

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 Hosts and Cross-Compilation.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.2 Getting the Canonical System Type

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 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.

Macro: AC_CANONICAL_BUILD

Compute the canonical build-system type variable, 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.

Macro: AC_CANONICAL_HOST

Compute the canonical host-system type variable, 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.

Macro: AC_CANONICAL_TARGET

Compute the canonical target-system type variable, 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 Hosts and Cross-Compilation, for more.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.3 Using the System Type

In `configure.ac' the system type is generally used by one or more case statements to select system-specifics. Shell wildcards can be used to match a group of system types.

For example, an extra assembler code object file could be chosen, giving access to a CPU cycle counter register. $(CYCLE_OBJ) in the following would be used in a makefile to add the object to a program or library.

 
AS_CASE([$host],
  [alpha*-*-*], [CYCLE_OBJ=rpcc.o],
  [i?86-*-*],   [CYCLE_OBJ=rdtsc.o],
  [CYCLE_OBJ=""]
)
AC_SUBST([CYCLE_OBJ])

AC_CONFIG_LINKS (see section Creating Configuration Links) is another good way to select variant source files, for example optimized code for some CPUs. The configured CPU type doesn't always indicate exact CPU types, so some runtime capability checks may be necessary too.

 
case $host in
  alpha*-*-*)   AC_CONFIG_LINKS([dither.c:alpha/dither.c]) ;;
  powerpc*-*-*) AC_CONFIG_LINKS([dither.c:powerpc/dither.c]) ;;
  *-*-*)        AC_CONFIG_LINKS([dither.c:generic/dither.c]) ;;
esac

The host system type can also be used to find cross-compilation tools with AC_CHECK_TOOL (see section Generic Program and File Checks).

The above examples all show `$host', since this is where the code is going to run. Only rarely is it necessary to test `$build' (which is where the build is being done).

Whenever you're tempted to use `$host' it's worth considering whether some sort of probe would be better. New system types come along periodically or previously missing features are added. Well-written probes can adapt themselves to such things, but hard-coded lists of names can't. Here are some guidelines,

`$target' is for use by a package creating a compiler or similar. For ordinary packages it's meaningless and should not be used. It indicates what the created compiler should generate code for, if it can cross-compile. `$target' generally selects various hard-coded CPU and system conventions, since usually the compiler or tools under construction themselves determine how the target works.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated on January, 20 2010 using texi2html 1.76.