Skip to content
Advertisement

Clarifying the “./configure” options “–build”, “–host” and “–target”

The script ./configure accepts the options –build, –host and –target. After reading a few post and articles, I am still confused on what exactly these options are and what software they include.

Here’s a snippet from the GNU website of the three terms:

There are three system names that the build knows about: the machine you are building on (build), the machine that you are building for (host), and the machine that GCC will produce code for (target). When you configure GCC, you specify these with –build=, –host=, and –target=.

Specifying the host without specifying the build should be avoided, as configure may (and once did) assume that the host you specify is also the build, which may not be true.

What exactly are they referring to when using the term “building on” or “building for”? From the post I have read, it seems “building on” refers to the system used to compile the debugger or compiler, and the host is the system that runs the debugger or compiler.

An example I came across in this article confused me on exactly what the “build” is “building”:

  • build: a powerpc build machine that you are going to do all compilation on
  • host: an x86 laptop that you are going to use for debugging these devices in the field
  • target: several embedded devices, with MIPS processors, which your code is going to run on

Since the PowerPC is doing the compilation for the MIPS devices, does this mean it’s a host as well as a build? Does this also mean systems that run debugging software are also classified as host system?

According to this article in a user’s comment, it’s mentioned that:

  • build = where am I compiling the compiler
  • host = where the compiler will run
  • target = what code will the compiler produce

So does this mean systems running compilers, linkers, and debugging can be classified as “hosts”? So what does the “building on” software include?

Here’s another snippet from the GNU website:

If build, host, and target are all the same, this is called a native. If build and host are the same but target is different, this is called a cross. If build, host, and target are all different this is called a canadian (for obscure reasons dealing with Canada’s political party and the background of the person working on the build at that time). If host and target are the same, but build is different, you are using a cross-compiler to build a native for a different system. Some people call this a host-x-host, crossed native, or cross-built native. If build and target are the same, but host is different, you are using a cross compiler to build a cross compiler that produces code for the machine you’re building on. This is rare, so there is no common way of describing it. There is a proposal to call this a crossback.

My understanding of this is as follows:

  • Native – my x86_64 machine I run and test my program is a native. The compiler/linker (gcc) was compiled and installed when I installed the OS, I use gcc to compile my code which I run natively on that same machine.
  • Cross – it’s now a cross if I use the same x86_64 machine to compile code for a MIPS device. The x86_64 machine is the host/build and the MIPS device is the target.
  • Canadian – a newer version of GCC gets released and I decide use another machine (PowerPC2) to compile and test the new compiler. Any future compilation of compilers will be done here and gcc wil be deployed on to my x86_64 once successfully tested. So the PowerPC2 is now the build, the X86_64 system is the host, and the MIPS device is target.
  • Cross-compiler – we’ll keep the build system as the PowerPC2, but now I compiling and running code on the same x86_64 host.
  • The last setup is rather odd and it does state “there’s no common way to describe when the build and target are the same, but host is different”. Why would you set up a system in this way?

Advertisement

Answer

It’s not that complicated with “normal” software: You have a build system (where the software is compiled) and a host system (where it will run). Often the two are identical (you produce software on your system for your system); but sometimes they are not, usually if the host system is not well suited to compile software, as with embedded devices, or when it is not (yet) available. This setup — when software is compiled on one system (type) but will run on a different system (type) — is called cross compilation.

If you compile a compiler though a third system comes into play because the compiler you build may be a cross compiler. The system for which the compiler you are building will generate code is called the target system. Often build and host system will be the same — your new compiler will run on the machine you are building it on, which is obviously well suited to compile software — but sometimes it is not; in that case you are building a compiler (build) which will run on a different system (host) where it will produce code for yet another system (target).

The post you link to describes a similar scenario, but for a debugger which is split into two parts. One part, the server, runs on the device being debugged, the other part, the gdb client, runs on an x86 laptop connecting to the embedded device.

Now a debugger, being something like a de-compiler, is similar to a compiler in that it groks machine code of a certain architecture. Like a compiler, not all parts of the debugger need to run on the machine which is being debugged; we can have a “cross-debugger” with a host (where it’s running) and a target (which architecture it understands). That’s the scenario here. There is

  • a gdbserver running on the embedded device being debugged
  • and a gdb client running on a “real machine” connecting to the server on the embedded device.

For both parts of the debugger the target is MIPS embedded devices, even though they do not produce code but interpret it.

For the gdb client the build, host and target systems are all different: It’s being built on a PowerPC, is hosted by an x86 and is targeted at — or understands the architecture of — MIPS embedded systems. For the gdb server the host and target system are identical (because it runs on the MIPS embedded device whose architecture it understands).

Because host and target are identical we have a classical cross compilation for the server; it is enough to just define “host” because the “target” defaults to “host” if not specified explicitly.

Advertisement