Node:Hosts and Cross-Compilation, Next:, Previous:New Macros, Up:Autoconf 2.13


Hosts and Cross-Compilation

Based on the experience of compiler writers, and after long public debates, many aspects of the cross-compilation chain have changed:


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 to cure).

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 will enter cross compilation mode, so it won't run any tests that require execution.

Hint: if you mean to override the result of config.guess, prefer --build over --host. In the future, --host will not override the name of the build system type. Whenever you specify --host, be sure to specify --build too.

For backward compatibility, configure will accept a system type as an option by itself. Such an option will override the defaults for build, host and target system types. The following configure statement will configure a cross toolchain that will run on NetBSD/alpha but generate code for GNU Hurd/sparc, which is also the build platform. 

./configure --host=alpha-netbsd sparc-gnu

In Autoconf, 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 by --build isn't, the build system will be assumed to be the same as --host, and build_alias will be 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 iff --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 a near future.

If you specify --host, but not --build, when configure performs the first compiler test it will try to run an executable produced by the compiler. If the execution fails, it will enter 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=i686-pc-linux-gnu --host=m68k-coff

will enter cross-compilation mode. The former interface, which consisted in setting the compiler to a cross-compiler without informing configure is obsolete. For instance, 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