By default configure builds for the current system.
To create binaries that can run on a different system type,
specify a --host=type option along with compiler
variables that specify how to generate object code for type.
For example, to create binaries intended to run on a 64-bit ARM
processor:
./configure --host=aarch64-linux-gnu \ CC=aarch64-linux-gnu-gcc \ CXX=aarch64-linux-gnu-g++
If done on a machine that can execute these binaries
(e.g., via qemu-aarch64, $QEMU_LD_PREFIX, and Linux’s
binfmt_misc capability), the build behaves like a native build.
Otherwise it is a cross-build: configure
will make cross-compilation guesses instead of running test programs,
and make check will not work.
A system type can either be a short name like ‘mingw64’, or a canonical name like ‘x86_64-pc-linux-gnu’. Canonical names have the form cpu-company-system where system is either os or kernel-os. To canonicalize and validate a system type, you can run the command config.sub, which is often squirreled away in a subdirectory like build-aux. For example:
$ build-aux/config.sub arm64-linux aarch64-unknown-linux-gnu $ build-aux/config.sub riscv-lnx Invalid configuration 'riscv-lnx': OS 'lnx' not recognized
You can look at the config.sub file to see which types are recognized. If the file is absent, this package does not need the system type.
If configure fails with the diagnostic “cannot guess build type”.
config.sub did not recognize your system’s type.
In this case, first fetch the newest versions of these files
from the GNU config package.
If that fixes things, please report it to the
maintainers of the package containing configure.
Otherwise, you can try the configure option
--build=type where type comes close to your
system type; also, please report the problem to
config-patches@gnu.org.
For more details about configuring system types, see Manual Configuration.