Simple question.

Sergey Ostrovsky sostrovs@kns.com
Thu Jan 3 05:21:00 GMT 2002


mike stump wrote:

> > Date: Wed, 2 Jan 2002 15:06:43 -0800 (PST)
> > From: Sir Ace <chandleg@wizardsworks.org>
> > To: gcc@gnu.org
>
> > I am having a very rough time trying to figure out something do to
> > the poor documentation on gcc.  What I need to do is build a native
> > compiler with a cross compiler.  My host platform is x86, the target
> > is Hitachi sh-4.
>
> > I have built and tested the cross compiler, it works great.
> > I can not get the damn thing to build a native compiler for the sh-4
> > it keeps failing when it tries to execute things during the make.
>
> > Here is what I am doing, Can you please tell me where I am messing up?:
>
> > ../gcc-3.0.1/configure --target=$TARGET --prefix=$PREFIX \
> > --disable-shared --host=$TARGET --enable-languages=c
>
> 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.

Man, it worth to read _every_ message on this list just to spot a gem like this
one !
Thanks !




More information about the Gcc mailing list