Next: AC_LIBOBJ
vs. LIBOBJS
, Previous: New Macros, Up: Upgrading From Version 2.13 [Contents][Index]
Based on the experience of compiler writers, and after long public debates, many aspects of the cross-compilation chain have changed:
configure
,
configure
,
The relationship between build, host, and target have been cleaned up:
the chain of default is now simply: target defaults to host, host to
build, and build to the result of config.guess
. Nevertheless,
in order to ease the transition from 2.13 to 2.50, the following
transition scheme is implemented. Do not rely on it, as it will
be completely disabled in a couple of releases (we cannot keep it, as it
proves to cause more problems than it cures).
They all default to the result of running config.guess
, unless
you specify either --build or --host. In this case,
the default becomes the system type you specified. If you specify both,
and they’re different, configure
enters cross compilation
mode, so it doesn’t run any tests that require execution.
Hint: if you mean to override the result of config.guess
,
prefer --build over --host.
For backward compatibility, configure
accepts a system
type as an option by itself. Such an option overrides the
defaults for build, host, and target system types. The following
configure statement configures a cross toolchain that runs on
NetBSD/alpha but generates code for GNU Hurd/sparc,
which is also the build platform.
./configure --host=alpha-netbsd sparc-gnu
In Autoconf 2.13 and before, the variables build
, host
,
and target
had a different semantics before and after the
invocation of AC_CANONICAL_BUILD
etc. Now, the argument of
--build is strictly copied into build_alias
, and is left
empty otherwise. After the AC_CANONICAL_BUILD
, build
is
set to the canonicalized build type. To ease the transition, before,
its contents is the same as that of build_alias
. Do not
rely on this broken feature.
For consistency with the backward compatibility scheme exposed above, when --host is specified but --build isn’t, the build system is assumed to be the same as --host, and ‘build_alias’ is set to that value. Eventually, this historically incorrect behavior will go away.
The former scheme to enable cross-compilation proved to cause more harm
than good, in particular, it used to be triggered too easily, leaving
regular end users puzzled in front of cryptic error messages.
configure
could even enter cross-compilation mode only
because the compiler was not functional. This is mainly because
configure
used to try to detect cross-compilation, instead of
waiting for an explicit flag from the user.
Now, configure
enters cross-compilation mode if and only if
--host is passed.
That’s the short documentation. To ease the transition between 2.13 and its successors, a more complicated scheme is implemented. Do not rely on the following, as it will be removed in the near future.
If you specify --host, but not --build, when
configure
performs the first compiler test it tries to run
an executable produced by the compiler. If the execution fails, it
enters cross-compilation mode. This is fragile. 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=x86_64-pc-linux-gnu --host=x86_64-w64-mingw64
enters cross-compilation mode. The former interface, which
consisted in setting the compiler to a cross-compiler without informing
configure
is obsolete. For instance, configure
fails if it can’t run the code generated by the specified compiler if you
configure as follows:
./configure CC=x86_64-w64-mingw64-gcc
Next: AC_LIBOBJ
vs. LIBOBJS
, Previous: New Macros, Up: Upgrading From Version 2.13 [Contents][Index]