configure.texi

来自「基于4个mips核的noc设计」· TEXI 代码 · 共 1,744 行 · 第 1/5 页

@table @var
@item cpu
The type of processor.  This is typically something like @samp{i386} or
@samp{sparc}.  More specific variants are used as well, such as
@samp{mipsel} to indicate a little endian MIPS processor.
@item manufacturer
A somewhat freeform field which indicates the manufacturer of the
system.  This is often simply @samp{unknown}.  Other common strings are
@samp{pc} for an IBM PC compatible system, or the name of a workstation
vendor, such as @samp{sun}.
@item operating_system
The name of the operating system which is run on the system.  This will
be something like @samp{solaris2.5} or @samp{irix6.3}.  There is no
particular restriction on the version number, and strings like
@samp{aix4.1.4.0} are seen.  For an embedded system, which has no
operating system, this field normally indicates the type of object file
format, such as @samp{elf} or @samp{coff}.
@item kernel
This is used mainly for GNU/Linux.  A typical GNU/Linux configuration
name is @samp{i586-pc-linux-gnulibc1}.  In this case the kernel,
@samp{linux}, is separated from the operating system, @samp{gnulibc1}.
@end table

The shell script @file{config.guess} will normally print the correct
configuration name for the system on which it is run.  It does by
running @samp{uname} and by examining other characteristics of the
system.

Because @file{config.guess} can normally determine the configuration
name for a machine, it is normally only necessary to specify a
configuration name when building a cross-compiler or when building using
a cross-compiler.

@node Using Configuration Names
@section Using Configuration Names

A configure script will sometimes have to make a decision based on a
configuration name.  You will need to do this if you have to compile
code differently based on something which can not be tested using a
standard autoconf feature test.

It is normally better to test for particular features, rather than to
test for a particular system.  This is because as Unix evolves,
different systems copy features from one another.  Even if you need to
determine whether the feature is supported based on a configuration
name, you should define a macro which describes the feature, rather than
defining a macro which describes the particular system you are on.

Testing for a particular system is normally done using a case statement
in @file{configure.in}.  The case statement might look something like
the following, assuming that @samp{host} is a shell variable holding a
canonical configuration name (which will be the case if
@file{configure.in} uses the @samp{AC_CANONICAL_HOST} or
@samp{AC_CANONICAL_SYSTEM} macro).

@smallexample
case "$@{host@}" in
i[3456]86-*-linux-gnu*) do something ;;
sparc*-sun-solaris2.[56789]*) do something ;;
sparc*-sun-solaris*) do something ;;
mips*-*-elf*) do something ;;
esac
@end smallexample

It is particularly important to use @samp{*} after the operating system
field, in order to match the version number which will be generated by
@file{config.guess}.

In most cases you must be careful to match a range of processor types.
For most processor families, a trailing @samp{*} suffices, as in
@samp{mips*} above.  For the i386 family, something along the lines of
@samp{i[3456]86} suffices at present.  For the m68k family, you will
need something like @samp{m68*}.  Of course, if you do not need to match
on the processor, it is simpler to just replace the entire field by a
@samp{*}, as in @samp{*-*-irix*}.

@node Cross Compilation Tools
@chapter Cross Compilation Tools
@cindex cross tools

The GNU configure and build system can be used to build @dfn{cross
compilation} tools.  A cross compilation tool is a tool which runs on
one system and produces code which runs on another system.

@menu
* Cross Compilation Concepts::		Cross Compilation Concepts.
* Host and Target::			Host and Target.
* Using the Host Type::			Using the Host Type.
* Specifying the Target::       	Specifying the Target.
* Using the Target Type::		Using the Target Type.
* Cross Tools in the Cygnus Tree::	Cross Tools in the Cygnus Tree
@end menu

@node Cross Compilation Concepts
@section Cross Compilation Concepts

@cindex cross compiler
A compiler which produces programs which run on a different system is a
cross compilation compiler, or simply a @dfn{cross compiler}.
Similarly, we speak of cross assemblers, cross linkers, etc.

In the normal case, a compiler produces code which runs on the same
system as the one on which the compiler runs.  When it is necessary to
distinguish this case from the cross compilation case, such a compiler
is called a @dfn{native compiler}.  Similarly, we speak of native
assemblers, etc.

Although the debugger is not strictly speaking a compilation tool, it is
nevertheless meaningful to speak of a cross debugger: a debugger which
is used to debug code which runs on another system.  Everything that is
said below about configuring cross compilation tools applies to the
debugger as well.

@node Host and Target
@section Host and Target
@cindex host system
@cindex target system

When building cross compilation tools, there are two different systems
involved: the system on which the tools will run, and the system for
which the tools generate code.

The system on which the tools will run is called the @dfn{host} system.

The system for which the tools generate code is called the @dfn{target}
system.

For example, suppose you have a compiler which runs on a GNU/Linux
system and generates ELF programs for a MIPS embedded system.  In this
case the GNU/Linux system is the host, and the MIPS ELF system is the
target.  Such a compiler could be called a GNU/Linux cross MIPS ELF
compiler, or, equivalently, a @samp{i386-linux-gnu} cross
@samp{mips-elf} compiler.

Naturally, most programs are not cross compilation tools.  For those
programs, it does not make sense to speak of a target.  It only makes
sense to speak of a target for tools like @samp{gcc} or the
@samp{binutils} which actually produce running code.  For example, it
does not make sense to speak of the target of a tool like @samp{bison}
or @samp{make}.

Most cross compilation tools can also serve as native tools.  For a
native compilation tool, it is still meaningful to speak of a target.
For a native tool, the target is the same as the host.  For example, for
a GNU/Linux native compiler, the host is GNU/Linux, and the target is
also GNU/Linux.

@node Using the Host Type
@section Using the Host Type

In almost all cases the host system is the system on which you run the
@samp{configure} script, and on which you build the tools (for the case
when they differ, @pxref{Canadian Cross}).

@cindex @samp{AC_CANONICAL_HOST}
If your configure script needs to know the configuration name of the
host system, and the package is not a cross compilation tool and
therefore does not have a target, put @samp{AC_CANONICAL_HOST} in
@file{configure.in}.  This macro will arrange to define a few shell
variables when the @samp{configure} script is run.

@table @samp
@item host
The canonical configuration name of the host.  This will normally be
determined by running the @file{config.guess} shell script, although the
user is permitted to override this by using an explicit @samp{--host}
option.
@item host_alias
In the unusual case that the user used an explicit @samp{--host} option,
this will be the argument to @samp{--host}.  In the normal case, this
will be the same as the @samp{host} variable.
@item host_cpu
@itemx host_vendor
@itemx host_os
The first three parts of the canonical configuration name.
@end table

The shell variables may be used by putting shell code in
@file{configure.in}.  For an example, see @ref{Using Configuration
Names}.

@node Specifying the Target
@section Specifying the Target

By default, the @samp{configure} script will assume that the target is
the same as the host.  This is the more common case; for example, it
leads to a native compiler rather than a cross compiler.

@cindex @samp{--target} option
@cindex target option
@cindex configure target
If you want to build a cross compilation tool, you must specify the
target explicitly by using the @samp{--target} option when you run
@samp{configure}.  The argument to @samp{--target} is the configuration
name of the system for which you wish to generate code.
@xref{Configuration Names}.

For example, to build tools which generate code for a MIPS ELF embedded
system, you would use @samp{--target mips-elf}.

@node Using the Target Type
@section Using the Target Type

@cindex @samp{AC_CANONICAL_SYSTEM}
When writing @file{configure.in} for a cross compilation tool, you will
need to use information about the target.  To do this, put
@samp{AC_CANONICAL_SYSTEM} in @file{configure.in}.

@samp{AC_CANONICAL_SYSTEM} will look for a @samp{--target} option and
canonicalize it using the @file{config.sub} shell script.  It will also
run @samp{AC_CANONICAL_HOST} (@pxref{Using the Host Type}).

The target type will be recorded in the following shell variables.  Note
that the host versions of these variables will also be defined by
@samp{AC_CANONICAL_HOST}.

@table @samp
@item target
The canonical configuration name of the target.
@item target_alias
The argument to the @samp{--target} option.  If the user did not specify
a @samp{--target} option, this will be the same as @samp{host_alias}.
@item target_cpu
@itemx target_vendor
@itemx target_os
The first three parts of the canonical target configuration name.
@end table

Note that if @samp{host} and @samp{target} are the same string, you can
assume a native configuration.  If they are different, you can assume a
cross configuration.

It is arguably possible for @samp{host} and @samp{target} to represent
the same system, but for the strings to not be identical.  For example,
if @samp{config.guess} returns @samp{sparc-sun-sunos4.1.4}, and somebody
configures with @samp{--target sparc-sun-sunos4.1}, then the slight
differences between the two versions of SunOS may be unimportant for
your tool.  However, in the general case it can be quite difficult to
determine whether the differences between two configuration names are
significant or not.  Therefore, by convention, if the user specifies a
@samp{--target} option without specifying a @samp{--host} option, it is
assumed that the user wants to configure a cross compilation tool.

The variables @samp{target} and @samp{target_alias} should be handled
differently.

In general, whenever the user may actually see a string,
@samp{target_alias} should be used.  This includes anything which may
appear in the file system, such as a directory name or part of a tool
name.  It also includes any tool output, unless it is clearly labelled
as the canonical target configuration name.  This permits the user to
use the @samp{--target} option to specify how the tool will appear to
the outside world.

On the other hand, when checking for characteristics of the target
system, @samp{target} should be used.  This is because a wide variety of
@samp{--target} options may map into the same canonical configuration
name.  You should not attempt to duplicate the canonicalization done by
@samp{config.sub} in your own code.

By convention, cross tools are installed with a prefix of the argument
used with the @samp{--target} option, also known as @samp{target_alias}
(@pxref{Using the Target Type}).  If the user does not use the
@samp{--target} option, and thus is building a native tool, no prefix is
used.

For example, if gcc is configured with @samp{--target mips-elf}, then
the installed binary will be named @samp{mips-elf-gcc}.  If gcc is
configured without a @samp{--target} option, then the installed binary
will be named @samp{gcc}.

The autoconf macro @samp{AC_ARG_PROGRAM} will handle this for you.  If
you are using automake, no more need be done; the programs will
automatically be installed with the correct prefixes.  Otherwise, see
the autoconf documentation for @samp{AC_ARG_PROGRAM}.

@node Cross Tools in the Cygnus Tree
@section Cross Tools in the Cygnus Tree

The Cygnus tree is used for various packages including gdb, the GNU
binutils, and egcs.  It is also, of course, used for Cygnus releases.

In the Cygnus tree, the top level @file{configure} script uses the old
Cygnus configure system, not autoconf.  The top level @file{Makefile.in}
is written to build packages based on what is in the source tree, and
supports building a large number of tools in a single
@samp{configure}/@samp{make} step.

The Cygnus tree may be configured with a @samp{--target} option.  The
@samp{--target} option applies recursively to every subdirectory, and
permits building an entire set of cross tools at once.

@menu
* Host and Target Libraries::		Host and Target Libraries.
* Target Library Configure Scripts::	Target Library Configure Scripts.
* Make Targets in Cygnus Tree::         Make Targets in Cygnus Tree.
* Target libiberty::			Target libiberty
@end menu

@node Host and Target Libraries
@subsection Host and Target Libraries

The Cygnus tree distinguishes host libraries from target libraries.

Host libraries are built with the compiler used to build the programs
which run on the host, which is called the host compiler.  This includes
libraries such as @samp{bfd} and @samp{tcl}.  These libraries are built
with the host compiler, and are linked into programs like the binutils
or gcc which run on the host.

Target libraries are built with the target compiler.  If gcc is present
in the source tree, then the target compiler is the gcc that is built
using the host compiler.  Target libraries are libraries such as
@samp{newlib} and @samp{libstdc++}.  These libraries are not linked into
the host programs, but are instead made available for use with programs
built with the target compiler.

For the rest of this section, assume that gcc is present in the source
tree, so that it will be used to build the target libraries.

There is a complication here.  The configure process needs to know which
compiler you are going to use to build a tool; otherwise, the feature
tests will not work correctly.  The Cygnus tree handles this by not
configuring the target libraries until the target compiler is built.  In
order to permit everything to build using a single
@samp{configure}/@samp{make}, the configuration of the target libraries
is actually triggered during the make step.

When the target libraries are configured, the @samp{--target} option is
not used.  Instead, the @samp{--host} option is used with the argument
of the @samp{--target} option for the overall configuration.  If no
@samp{--target} option was used for the overall configuration, the
@samp{--host} option will be passed with the output of the
@file{config.guess} shell script.  Any @samp{--build} option is passed
down unchanged.

This translation of configuration options is done because since the
target libraries are compiled with the target compiler, they are being
built in order to run on the target of the overall configuration.  By
the definition of host, this means that their host system is the same as
the target system of the overall configuration.

The same process is used for both a native configuration and a cross
configuration.  Even when using a native configuration, the target
libraries will be configured and built using the newly built compiler.
This is particularly important for the C++ libraries, since there is no
reason to assume that the C++ compiler used to build the host tools (if
there even is one) uses the same ABI as the g++ comp