File: autoconf.info,  Node: Specifying Target Triplets,  Next: Canonicalizing,  Up: Manual Configuration

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’ (*note System Types::.  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’.
     Specifying a BUILD-TYPE that differs from HOST-TYPE enables
     cross-compilation mode.

‘--host=HOST-TYPE’
     the type of system on which the package runs.  By default it is the
     same as the build machine.  The tools that get used to build and
     manipulate binaries will, by default, all be prefixed with
     ‘HOST-TYPE-’, such as ‘HOST-TYPE-gcc’, ‘HOST-TYPE-g++’,
     ‘HOST-TYPE-ar’, and ‘HOST-TYPE-nm’.  If the binaries produced by
     these tools can be executed by the build system, the configure
     script will make use of it in ‘AC_RUN_IFELSE’ invocations;
     otherwise, cross-compilation mode is enabled.  Specifying a
     HOST-TYPE that differs from BUILD-TYPE, when BUILD-TYPE was also
     explicitly specified, equally enables 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’ but still
produce binaries for the build machine, use ‘--build’, not ‘--host’.

   So, for example, to produce binaries for 64-bit MinGW, use a command
like this:

     ./configure --host=x86_64-w64-mingw64

   If your system has the ability to execute MinGW binaries but you
don't want to make use of this feature and instead prefer
cross-compilation guesses, use a command like this:

     ./configure --build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw64

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=x86_64-w64-mingw64-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
‘x86_64-w64-mingw64-gcc’ and ‘x86_64-w64-mingw64-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 *note Hosts and Cross-Compilation::.