This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simple question.



I swear, I never saw this before.....

Ever...   really.
{grin}

> What part of the doc (I'll quote it below) was unclear?  I think you
> missed the --build flag.
> 
> You either need that, or you need an a.out sh executor/emulator
> strapped into your OS (yes, you can do this on linux).
> 
> 
> @section Configure Terms and History
> @cindex configure terms
> @cindex canadian
> 
> This section is not instructions for building GCC.  If you are trying to
> do a build, you should first read @uref{http://gcc.gnu.org/install/} or
> whatever installation instructions came with your source package.
> 
> The configure and build process has a long and colorful history, and can
> be confusing to anyone who doesn't know why things are the way they are.
> While there are other documents which describe the configuration process
> in detail, here are a few things that everyone working on GCC should
> know.
> 
> There are three system names that the build knows about: the machine you
> are building on (@dfn{build}), the machine that you are building for
> (@dfn{host}), and the machine that GCC will produce code for
> (@dfn{target}).  When you configure GCC, you specify these with
> @option{--build=}, @option{--host=}, and @option{--target=}.
> 
> Specifying the host without specifying the build should be avoided, as
> @command{configure} may (and once did) assume that the host you specify
> is also the build, which may not be true.
> 
> If build, host, and target are all the same, this is called a
> @dfn{native}.  If build and host are the same but target is different,
> this is called a @dfn{cross}.  If build, host, and target are all
> different this is called a @dfn{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 @dfn{host-x-host},
> @dfn{crossed native}, or @dfn{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
> (although I propose calling it a @dfn{crossback}).
> 
> If build and host are the same, the GCC you are building will also be
> used to build the target libraries (like @code{libstdc++}).  If build and host
> are different, you must have already build and installed a cross
> compiler that will be used to build the target libraries (if you
> configured with @option{--target=foo-bar}, this compiler will be called
> @command{foo-bar-gcc}).
> 
> In the case of target libraries, the machine you're building for is the
> machine you specified with @option{--target}.  So, build is the machine
> you're building on (no change there), host is the machine you're
> building for (the target libraries are built for the target, so host is
> the target you specified), and target doesn't apply (because you're not
> building a compiler, you're building libraries).  The configure/make
> process will adjust these variables as needed.  It also sets
> @code{$with_cross_host} to the original @option{--host} value in case you
> need it.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]