Let us assume for a moment that you have a sun4 and that with your sun4 you received a development environment. This development environment is intended to be run on your sun4 to build programs that can be run on your sun4. You could, for instance, run this development environment on your sun4 to build our example desk calculator program. You could then run the desk calculator program on your sun4.
The resulting desk calculator program is referred to as a native program. The development environment itself is composed of native programs that, when run, build other native programs. Any other program is referred to as foreign. Programs intended for other machines are foreign programs.
This type of development environment, which is by far the most common, is refered to as native. That is, a native development environment runs on some machine to build programs for that same machine. The process of using a native development environment to build native programs is called a native build.
./configure sun4
will configure this source such that when built in a sun4 development environment, with a development environment that builds programs intended to be run on sun4 machines, the programs built will be native programs and the resulting development environment will be a native development environment.
The development system that came with your sun4 is one such environment. Using it to build the GNU Development Tools is a very common activity and the resulting development environment is quite popular.
make all
will build the tools as configured and will assume that you want to use the native development environment that came with your machine.
Using a development environment to build a development environment is called bootstrapping. The Cygnus Support release of the GNU Development Tools is capable of bootstrapping itself. This is a very powerful feature that we'll return to later. For now, let's pretend that you used the native development environment that came with your sun4 to bootstrap the Cygnus Support release and let's call the new development environment stage1.
Why bother? Well, most people find that the GNU development environment builds programs that run faster and take up less space than the native development environments that came with their machines. Some people didn't get development environments with their machines and some people just like using the GNU tools better than using other tools.
While you're at it, if the GNU tools produce better programs, maybe you should use them to build the GNU tools. It's a good idea, so let's pretend that you do. Let's call the new development environment stage2.
So far you've built a development environment, stage1, and you've used stage1 to build a new, faster and smaller development environment, stage2, but you haven't run any of the programs that the GNU tools have built. You really don't yet know if these tools work. Do you have any programs built with the GNU tools? Yes, you do. stage2. What does that program do? It builds programs. Ok, do you have any source handy to build into a program? Yes, you do. The GNU tools themselves. In fact, if you use stage2 to build the GNU tools again the resulting programs should be identical to stage2. Let's pretend that you do and call the new development environment stage3.
You've just completed what's called a three stage boot. You now have a small, fast, somewhat tested, development environment.
make bootstrap
will do a three stage boot across all tools and will compare stage2 to stage3 and complain if they are not identical.
Once built,
make install
will install the development environment in the default location or in
$(prefix) if you specified an alternate when you configured.
Any development environment that is not a native development environment is refered to as a cross development environment. There are many different types of cross development environments but most fall into one of three basic categories.
The first category of cross development environment is called emulation. There are two primary types of emulation, but both types result in programs that run on the native host.
The first type is software emulation. This form of cross development environment involves a native program that when run on the native host, is capable of interpreting, and in most aspects running, a program intended for some other machine. This technique is typically used when the other machine is either too expensive, too slow, too fast, or not available, perhaps because it hasn't yet been built. The native, interpreting program is called a software emulator.
The GNU Development Tools do not currently include any software emulators. Some do exist and the GNU Development Tools can be configured to create simple cross development environments for with these emulators. More on this later.
The second type of emulation is when source intended for some other development environment is built into a program intended for the native host. The concepts of operating system universes and hosted operating systems are two such development environments.
The Cygnus Support Release of the GNU Development Tools can be configured for one such emulation at this time.
./configure sun4 -ansi
will configure the source such that when built in a sun4 development environment the resulting development environment is capable of building sun4 programs from strictly conforming ANSI X3J11 C source. Remember that the environment used to build the tools determines the machine on which this tools will run, so the resulting programs aren't necessarily intended to run on a sun4, although they usually are. Also note that the source for the GNU tools is not strictly conforming ANSI source so this configuration cannot be used to bootstrap the GNU tools.
./configure sun4 -target=a29k
will configure the tools such that when compiled in a sun4 development environment the resulting development environment can be used to create programs intended for an a29k. Again, this does not necessarily mean that the new development environment can be run on a sun4. That would depend on the development environment used to build these tools.
Earlier you saw how to configure the tools to build a native development environment, that is, a development environment that runs on your sun4 and builds programs for your sun4. Let's pretend that you use stage3 to build this simple cross configuration and let's call the new development environment gcc-a29k. Remember that this is a native build. Gcc-a29k is a collection of native programs intended to run on your sun4. That's what stage3 builds, programs for your sun4. Gcc-a29k represents an a29k development environment that builds programs intended to run on an a29k. But, remember, gcc-a29k runs on your sun4. Programs built with gcc-a29k will run on your sun4 only with the help of an appropriate software emulator.
Building gcc-a29k is also a bootstrap but of a slightly different sort. We call gcc-a29k a simple cross environment and using gcc-a29k to build a program intended for a29k is called crossing to a29k. Simple cross environments are the second category of cross development environments.
./configure a29k -target=a29k
will configure the tools such that when compiled in an a29k development environment, the resulting development environment can be used to create programs intended for an a29k. Again, this does not necessarily mean that the new development environment can be run on an a29k. That would depend on the development environment used to build these tools.
If you've been following along this walk through, then you've already built an a29k environment, namely gcc-a29k. Let's pretend you use gcc-a29k to build the current configuration.
Gcc-a29k builds programs intended for the a29k so the new development environment will be intended for use on an a29k. That is, this new gcc consists of programs that are foreign to your sun4. They cannot be run on your sun4.
The process of building this configuration is another a bootstrap. This bootstrap is also a cross to a29k. Because this type of build is both a bootstrap and a cross to a29k, it is sometimes referred to as a cross into a29k. This new development environment isn't really a cross development environment at all. It is intended to run on an a29k to produce programs for an a29k. You'll remember that this makes it, by definition, an a29k native compiler. Crossing into has been introduced here not because it is a type of cross development environment, but because it is frequently mistaken as one. The process is a cross but the resulting development environment is a native development environment.
You could not have built this configuration with stage3, because stage3 doesn't provide an a29k environment. Instead it provides a sun4 environment.
If you happen to have an a29k lying around, you could now use this fresh development environment on the a29k to three-stage these tools all over again. This process would look just like it did when we built the native sun4 development environment because we would be building another native development environment, this one on a29k.
So far you've seen that our development environment source must be configured for a specific host and for a specific target. You've also seen that the resulting development environment depends on the development environment used in the build process.
When all four match identically, that is, the configured host, the configured target, the environment presented by the development environment used in the build, and the machine on which the resulting development environment is intended to run, then the new development environment will be a native development environment.
When all four match except the configured host, then we can assume that the development environment used in the build is some form of library emulation.
When all four match except for the configured target, then the resulting development environment will be a simple cross development environment.
When all four match except for the host on which the development environment used in the build runs, the build process is a cross into and the resulting development environment will be native to some other machine.
Most of the other permutations do exist in some form, but only one more is interesting to the current discussion.
./configure a29k -target=sun3
will configure the tools such that when compiled in an a29k development environment, the resulting development environment can be used to create programs intended for a sun3. Again, this does not necessarily mean that the new development environment can be run on an a29k. That would depend on the development environment used to build these tools.
If you are still following along, then you have two a29k development environments, the native development environment that runs on a29k, and the simple cross that runs on your sun4. If you use the a29k native development environment on the a29k, you will be doing the same thing we did a while back, namely building a simple cross from a29k to sun3. Let's pretend that instead, you use gcc-a29k, the simple cross development environment that runs on sun4 but produces programs for a29k.
The resulting development environment will run on a29k because that's what gcc-a29k builds, a29k programs. This development environment will produce programs for a sun3 because that is how it was configured. This means that the resulting development environment is a simple cross.
There really isn't a common name for this process because very few development environments are capable of being configured this extensively. For the sake of discussion, let's call this process a Canadian cross. It's a three party cross, Canada has a three party system, hence Canadian Cross.