Let us assume for a moment that you have a sun4 and that with your sun4you received a development environment.  This development environment isintended to be run on your sun4 to build programs that can be run onyour sun4.  You could, for instance, run this development environment onyour sun4 to build our example desk calculator program.  You could thenrun the desk calculator program on your sun4.@cindex Native@cindex ForeignThe resulting desk calculator program is referred to as a @emph{native}program.  The development environment itself is composed of nativeprograms that, when run, build other native programs.  Any other programis referred to as @emph{foreign}.  Programs intended for other machines areforeign programs.This type of development environment, which is by far the most common,is refered to as @emph{native}.  That is, a native development environmentruns on some machine to build programs for that same machine.  Theprocess of using a native development environment to build nativeprograms is called a @emph{native} build.@example./configure sun4@end example@noindentwill configure this source such that when built in a sun4 developmentenvironment, with a development environment that builds programsintended to be run on sun4 machines, the programs built will be nativeprograms and the resulting development environment will be a nativedevelopment environment.The development system that came with your sun4 is one such environment.Using it to build the @sc{gnu} Development Tools is a very common activityand the resulting development environment is quite popular.@examplemake all@end example@noindentwill build the tools as configured and will assume that you want to usethe native development environment that came with your machine.@cindex Bootstrapping@cindex Stage1Using a development environment to build a development environment iscalled @emph{bootstrapping}.  The Cygnus Support release of the @sc{gnu}Development Tools is capable of bootstrapping itself.  This is a verypowerful feature that we'll return to later.  For now, let's pretendthat you used the native development environment that came with yoursun4 to bootstrap the Cygnus Support release and let's call the newdevelopment environment @emph{stage1}.Why bother?  Well, most people find that the @sc{gnu} developmentenvironment builds programs that run faster and take up less space thanthe native development environments that came with their machines.  Somepeople didn't get development environments with their machines and somepeople just like using the @sc{gnu} tools better than using other tools.@cindex Stage2While you're at it, if the @sc{gnu} tools produce better programs, maybe youshould use them to build the @sc{gnu} tools.  It's a good idea, so let'spretend that you do.  Let's call the new development environment@emph{stage2}.@cindex Stage3So far you've built a development environment, stage1, and you've usedstage1 to build a new, faster and smaller development environment,stage2, but you haven't run any of the programs that the @sc{gnu} tools havebuilt.  You really don't yet know if these tools work.  Do you have anyprograms built with the @sc{gnu} tools?  Yes, you do.  stage2.  What doesthat program do?  It builds programs.  Ok, do you have any source handyto build into a program?  Yes, you do.  The @sc{gnu} tools themselves.  Infact, if you use stage2 to build the @sc{gnu} tools again the resultingprograms should be identical to stage2.  Let's pretend that you do andcall the new development environment @emph{stage3}.@cindex Three stage bootYou've just completed what's called a @emph{three stage boot}.  You now havea small, fast, somewhat tested, development environment.@examplemake bootstrap@end example@noindentwill do a three stage boot across all tools and will compare stage2 tostage3 and complain if they are not identical.Once built,@examplemake install@end example@noindentwill install the development environment in the default location or in@code{$(prefix)} if you specified an alternate when you configured.@cindex CrossAny development environment that is not a native development environmentis refered to as a @emph{cross} development environment.  There are manydifferent types of cross development environments but most fall into oneof three basic categories.@node Emulation Environments, Simple Cross Environments, Native Development Environments, A Walk Through@section Emulation Environments@cindex EmulationThe first category of cross development environment is called@emph{emulation}.  There are two primary types of emulation, but bothtypes result in programs that run on the native host.@cindex Software emulation@cindex Software emulatorThe first type is @emph{software emulation}.  This form of crossdevelopment environment involves a native program that when run on thenative host, is capable of interpreting, and in most aspects running, aprogram intended for some other machine.  This technique is typicallyused 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 @emph{software emulator}.The @sc{gnu} Development Tools do not currently include any softwareemulators.  Some do exist and the @sc{gnu} Development Tools can beconfigured to create simple cross development environments for withthese emulators.  More on this later.The second type of emulation is when source intended for some otherdevelopment environment is built into a program intended for the nativehost.  The concepts of operating system universes and hosted operatingsystems are two such development environments.The Cygnus Support Release of the @sc{gnu} Development Tools can beconfigured for one such emulation at this time.@example./configure sun4 -ansi@end example@cindex ANSI@cindex X3J11@noindentwill configure the source such that when built in a sun4 developmentenvironment the resulting development environment is capable of buildingsun4 programs from strictly conforming @sc{ANSI X3J11 C} source.Remember that the environment used to build the tools determines themachine on which this tools will run, so the resulting programs aren'tnecessarily intended to run on a sun4, although they usually are.  Alsonote that the source for the @sc{gnu} tools is not strictly conforming@sc{ansi} source so this configuration cannot be used to bootstrap the@sc{gnu} tools.@node Simple Cross Environments, Crossing Into Targets, Emulation Environments, A Walk Through@section Simple Cross Environments@example./configure sun4 -target=a29k@end example@noindentwill configure the tools such that when compiled in a sun4 developmentenvironment the resulting development environment can be used to createprograms intended for an a29k.  Again, this does not necessarily meanthat the new development environment can be run on a sun4.  That woulddepend on the development environment used to build these tools.Earlier you saw how to configure the tools to build a native developmentenvironment, that is, a development environment that runs on your sun4and builds programs for your sun4.  Let's pretend that you use stage3 tobuild this simple cross configuration and let's call the new developmentenvironment gcc-a29k.  Remember that this is a native build.  Gcc-a29kis a collection of native programs intended to run on your sun4.  That'swhat stage3 builds, programs for your sun4.  Gcc-a29k represents an a29kdevelopment environment that builds programs intended to run on an a29k.But, remember, gcc-a29k runs on your sun4.  Programs built with gcc-a29kwill run on your sun4 only with the help of an appropriate softwareemulator.@cindex Simple cross@cindex Crossing toBuilding gcc-a29k is also a bootstrap but of a slightly different sort.We call gcc-a29k a @emph{simple cross} environment and using gcc-a29k tobuild a program intended for a29k is called @emph{crossing to} a29k.Simple cross environments are the second category of cross developmentenvironments.@node Crossing Into Targets, Canadian Cross, Simple Cross Environments, A Walk Through@section Crossing Into Targets@example./configure a29k -target=a29k@end example@noindentwill configure the tools such that when compiled in an a29k developmentenvironment, the resulting development environment can be used to createprograms intended for an a29k.  Again, this does not necessarily meanthat the new development environment can be run on an a29k.  That woulddepend on the development environment used to build these tools.If you've been following along this walk through, then you've alreadybuilt an a29k environment, namely gcc-a29k.  Let's pretend you usegcc-a29k to build the current configuration.Gcc-a29k builds programs intended for the a29k so the new developmentenvironment will be intended for use on an a29k.  That is, this new gccconsists of programs that are foreign to your sun4.  They cannot be runon your sun4.@cindex Crossing intoThe process of building this configuration is another a bootstrap.  Thisbootstrap is also a cross to a29k.  Because this type of build is both abootstrap and a cross to a29k, it is sometimes referred to as a@emph{cross into} a29k.  This new development environment isn't really across development environment at all.  It is intended to run on an a29kto produce programs for an a29k.  You'll remember that this makes it, bydefinition, an a29k native compiler.  @emph{Crossing into} has beenintroduced here not because it is a type of cross developmentenvironment, but because it is frequently mistaken as one.  The processis @emph{a cross} but the resulting development environment is a nativedevelopment environment.You could not have built this configuration with stage3, because stage3doesn't provide an a29k environment.  Instead it provides a sun4environment.If you happen to have an a29k lying around, you could now use this freshdevelopment environment on the a29k to three-stage these tools all overagain.  This process would look just like it did when we built thenative sun4 development environment because we would be building anothernative development environment, this one on a29k.@node Canadian Cross,  , Crossing Into Targets, A Walk Through@section Canadian CrossSo far you've seen that our development environment source must beconfigured for a specific host and for a specific target.  You've alsoseen that the resulting development environment depends on thedevelopment environment used in the build process.When all four match identically, that is, the configured host, theconfigured target, the environment presented by the developmentenvironment used in the build, and the machine on which the resultingdevelopment environment is intended to run, then the new developmentenvironment will be a native development environment.When all four match except the configured host, then we can assume thatthe development environment used in the build is some form of libraryemulation.When all four match except for the configured target, then the resultingdevelopment environment will be a simple cross development environment.When all four match except for the host on which the developmentenvironment used in the build runs, the build process is a @emph{cross into}and the resulting development environment will be native to some othermachine.Most of the other permutations do exist in some form, but only one moreis interesting to the current discussion.@example./configure a29k -target=sun3@end example@noindentwill configure the tools such that when compiled in an a29k developmentenvironment, the resulting development environment can be used to createprograms intended for a sun3.  Again, this does not necessarily meanthat the new development environment can be run on an a29k.  That woulddepend on the development environment used to build these tools.If you are still following along, then you have two a29k developmentenvironments, the native development environment that runs on a29k, andthe simple cross that runs on your sun4.  If you use the a29k nativedevelopment environment on the a29k, you will be doing the same thing wedid a while back, namely building a simple cross from a29k to sun3.Let's pretend that instead, you use gcc-a29k, the simple crossdevelopment environment that runs on sun4 but produces programs fora29k.The resulting development environment will run on a29k because that'swhat gcc-a29k builds, a29k programs.  This development environment willproduce programs for a sun3 because that is how it was configured.  Thismeans that the resulting development environment is a simple cross.@cindex Canadian Cross@cindex Three party crossThere really isn't a common name for this process because very fewdevelopment environments are capable of being configured thisextensively.  For the sake of discussion, let's call this process a@emph{Canadian cross}.  It's a three party cross, Canada has a threeparty system, hence Canadian Cross.@node Final Notes, Index, A Walk Through, top@chapter Final NotesBy @emph{configures}, I mean that links, Makefile, .gdbinit, andconfig.status are built.  Configuration is always done from the sourcedirectory.@table @code@item ./configure @var{name}configures this directory, perhaps recursively, for a single host+targetpair where the host and target are both @var{name}.  If a previousconfiguration existed, it will be overwritten.@item ./configure @var{hostname} -target=@var{targetname}configures this directory, perhaps recursively, for a single host+targetpair where the host is @var{hostname} and target is @var{targetname}.If a previous configuration existed, it will be overwritten.@end table@menu* Hacking Configurations::	Hacking Configurations@end menu@node Hacking Configurations,  , Final Notes, Final Notes@section Hacking ConfigurationsThe configure scripts essentially do three things, create subdirectoriesif appropriate, build a @file{Makefile}, and create links to files, allbased on and tailored to, a specific host+target pair.  The scripts alsocreate a @file{.gdbinit} if appropriate but this is not tailored.The Makefile is created by prepending some variable definitions to aMakefile template called @file{Makefile.in} and then inserting host andtarget specific Makefile fragments.  The variables are set based on thechosen host+target pair and build style, that is, if you use@code{-srcdir} or not.  The host and target specific Makefile may or maynot exist.@itemize @bullet@itemMakefiles can be edited directly, but those changes will eventually belost.  Changes intended to be permanent for a specific host should bemade to the host specific Makefile fragment.  This should be in@file{./config/mh-@var{host}} if it exists.  Changes intended to bepermanent for a specific target should be made to the target specificMakefile fragment.  This should be in @file{./config/mt-@var{target}} ifit exists.  Changes intended to be permanent for the directory should bemade in @file{Makefile.in}.  To propogate changes to any of these,either use @code{make Makefile} or @code{./config.status} orre-configure.@end itemize@page@node Index,  , Final Notes, top@appendix Index@printindex cp@contents@bye@c Local Variables:@c fill-column: 72@c End: