This is configure.info, produced by makeinfo version 4.0 from
|
This is configure.info, produced by makeinfo version 4.0 from
|
./configure.texi.
|
./configure.texi.
|
|
|
INFO-DIR-SECTION GNU admin
|
INFO-DIR-SECTION GNU admin
|
START-INFO-DIR-ENTRY
|
START-INFO-DIR-ENTRY
|
* configure: (configure). The GNU configure and build system
|
* configure: (configure). The GNU configure and build system
|
END-INFO-DIR-ENTRY
|
END-INFO-DIR-ENTRY
|
|
|
This file documents the GNU configure and build system.
|
This file documents the GNU configure and build system.
|
|
|
Copyright (C) 1998 Cygnus Solutions.
|
Copyright (C) 1998 Cygnus Solutions.
|
|
|
Permission is granted to make and distribute verbatim copies of this
|
Permission is granted to make and distribute verbatim copies of this
|
manual provided the copyright notice and this permission notice are
|
manual provided the copyright notice and this permission notice are
|
preserved on all copies.
|
preserved on all copies.
|
|
|
Permission is granted to copy and distribute modified versions of
|
Permission is granted to copy and distribute modified versions of
|
this manual under the conditions for verbatim copying, provided that
|
this manual under the conditions for verbatim copying, provided that
|
the entire resulting derived work is distributed under the terms of a
|
the entire resulting derived work is distributed under the terms of a
|
permission notice identical to this one.
|
permission notice identical to this one.
|
|
|
Permission is granted to copy and distribute translations of this
|
Permission is granted to copy and distribute translations of this
|
manual into another language, under the above conditions for modified
|
manual into another language, under the above conditions for modified
|
versions, except that this permission notice may be stated in a
|
versions, except that this permission notice may be stated in a
|
translation approved by the Foundation.
|
translation approved by the Foundation.
|
|
|
|
|
File: configure.info, Node: Configuration Name Definition, Next: Using Configuration Names, Up: Configuration Names
|
File: configure.info, Node: Configuration Name Definition, Next: Using Configuration Names, Up: Configuration Names
|
|
|
Configuration Name Definition
|
Configuration Name Definition
|
=============================
|
=============================
|
|
|
This is a string of the form CPU-MANUFACTURER-OPERATING_SYSTEM. In
|
This is a string of the form CPU-MANUFACTURER-OPERATING_SYSTEM. In
|
some cases, this is extended to a four part form:
|
some cases, this is extended to a four part form:
|
CPU-MANUFACTURER-KERNEL-OPERATING_SYSTEM.
|
CPU-MANUFACTURER-KERNEL-OPERATING_SYSTEM.
|
|
|
When using a configuration name in a configure option, it is normally
|
When using a configuration name in a configure option, it is normally
|
not necessary to specify an entire name. In particular, the
|
not necessary to specify an entire name. In particular, the
|
MANUFACTURER field is often omitted, leading to strings such as
|
MANUFACTURER field is often omitted, leading to strings such as
|
`i386-linux' or `sparc-sunos'. The shell script `config.sub' will
|
`i386-linux' or `sparc-sunos'. The shell script `config.sub' will
|
translate these shortened strings into the canonical form. autoconf
|
translate these shortened strings into the canonical form. autoconf
|
will arrange for `config.sub' to be run automatically when it is needed.
|
will arrange for `config.sub' to be run automatically when it is needed.
|
|
|
The fields of a configuration name are as follows:
|
The fields of a configuration name are as follows:
|
|
|
CPU
|
CPU
|
The type of processor. This is typically something like `i386' or
|
The type of processor. This is typically something like `i386' or
|
`sparc'. More specific variants are used as well, such as
|
`sparc'. More specific variants are used as well, such as
|
`mipsel' to indicate a little endian MIPS processor.
|
`mipsel' to indicate a little endian MIPS processor.
|
|
|
MANUFACTURER
|
MANUFACTURER
|
A somewhat freeform field which indicates the manufacturer of the
|
A somewhat freeform field which indicates the manufacturer of the
|
system. This is often simply `unknown'. Other common strings are
|
system. This is often simply `unknown'. Other common strings are
|
`pc' for an IBM PC compatible system, or the name of a workstation
|
`pc' for an IBM PC compatible system, or the name of a workstation
|
vendor, such as `sun'.
|
vendor, such as `sun'.
|
|
|
OPERATING_SYSTEM
|
OPERATING_SYSTEM
|
The name of the operating system which is run on the system. This
|
The name of the operating system which is run on the system. This
|
will be something like `solaris2.5' or `irix6.3'. There is no
|
will be something like `solaris2.5' or `irix6.3'. There is no
|
particular restriction on the version number, and strings like
|
particular restriction on the version number, and strings like
|
`aix4.1.4.0' are seen. For an embedded system, which has no
|
`aix4.1.4.0' are seen. For an embedded system, which has no
|
operating system, this field normally indicates the type of object
|
operating system, this field normally indicates the type of object
|
file format, such as `elf' or `coff'.
|
file format, such as `elf' or `coff'.
|
|
|
KERNEL
|
KERNEL
|
This is used mainly for GNU/Linux. A typical GNU/Linux
|
This is used mainly for GNU/Linux. A typical GNU/Linux
|
configuration name is `i586-pc-linux-gnulibc1'. In this case the
|
configuration name is `i586-pc-linux-gnulibc1'. In this case the
|
kernel, `linux', is separated from the operating system,
|
kernel, `linux', is separated from the operating system,
|
`gnulibc1'.
|
`gnulibc1'.
|
|
|
The shell script `config.guess' will normally print the correct
|
The shell script `config.guess' will normally print the correct
|
configuration name for the system on which it is run. It does by
|
configuration name for the system on which it is run. It does by
|
running `uname' and by examining other characteristics of the system.
|
running `uname' and by examining other characteristics of the system.
|
|
|
Because `config.guess' can normally determine the configuration name
|
Because `config.guess' can normally determine the configuration name
|
for a machine, it is normally only necessary to specify a configuration
|
for a machine, it is normally only necessary to specify a configuration
|
name when building a cross-compiler or when building using a
|
name when building a cross-compiler or when building using a
|
cross-compiler.
|
cross-compiler.
|
|
|
|
|
File: configure.info, Node: Using Configuration Names, Prev: Configuration Name Definition, Up: Configuration Names
|
File: configure.info, Node: Using Configuration Names, Prev: Configuration Name Definition, Up: Configuration Names
|
|
|
Using Configuration Names
|
Using Configuration Names
|
=========================
|
=========================
|
|
|
A configure script will sometimes have to make a decision based on a
|
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
|
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
|
code differently based on something which can not be tested using a
|
standard autoconf feature test.
|
standard autoconf feature test.
|
|
|
It is normally better to test for particular features, rather than to
|
It is normally better to test for particular features, rather than to
|
test for a particular system. This is because as Unix evolves,
|
test for a particular system. This is because as Unix evolves,
|
different systems copy features from one another. Even if you need to
|
different systems copy features from one another. Even if you need to
|
determine whether the feature is supported based on a configuration
|
determine whether the feature is supported based on a configuration
|
name, you should define a macro which describes the feature, rather than
|
name, you should define a macro which describes the feature, rather than
|
defining a macro which describes the particular system you are on.
|
defining a macro which describes the particular system you are on.
|
|
|
Testing for a particular system is normally done using a case
|
Testing for a particular system is normally done using a case
|
statement in `configure.in'. The case statement might look something
|
statement in `configure.in'. The case statement might look something
|
like the following, assuming that `host' is a shell variable holding a
|
like the following, assuming that `host' is a shell variable holding a
|
canonical configuration name (which will be the case if `configure.in'
|
canonical configuration name (which will be the case if `configure.in'
|
uses the `AC_CANONICAL_HOST' or `AC_CANONICAL_SYSTEM' macro).
|
uses the `AC_CANONICAL_HOST' or `AC_CANONICAL_SYSTEM' macro).
|
|
|
case "${host}" in
|
case "${host}" in
|
i[3456]86-*-linux-gnu*) do something ;;
|
i[3456]86-*-linux-gnu*) do something ;;
|
sparc*-sun-solaris2.[56789]*) do something ;;
|
sparc*-sun-solaris2.[56789]*) do something ;;
|
sparc*-sun-solaris*) do something ;;
|
sparc*-sun-solaris*) do something ;;
|
mips*-*-elf*) do something ;;
|
mips*-*-elf*) do something ;;
|
esac
|
esac
|
|
|
It is particularly important to use `*' after the operating system
|
It is particularly important to use `*' after the operating system
|
field, in order to match the version number which will be generated by
|
field, in order to match the version number which will be generated by
|
`config.guess'.
|
`config.guess'.
|
|
|
In most cases you must be careful to match a range of processor
|
In most cases you must be careful to match a range of processor
|
types. For most processor families, a trailing `*' suffices, as in
|
types. For most processor families, a trailing `*' suffices, as in
|
`mips*' above. For the i386 family, something along the lines of
|
`mips*' above. For the i386 family, something along the lines of
|
`i[3456]86' suffices at present. For the m68k family, you will need
|
`i[3456]86' suffices at present. For the m68k family, you will need
|
something like `m68*'. Of course, if you do not need to match on the
|
something like `m68*'. Of course, if you do not need to match on the
|
processor, it is simpler to just replace the entire field by a `*', as
|
processor, it is simpler to just replace the entire field by a `*', as
|
in `*-*-irix*'.
|
in `*-*-irix*'.
|
|
|
|
|
File: configure.info, Node: Cross Compilation Tools, Next: Canadian Cross, Prev: Configuration Names, Up: Top
|
File: configure.info, Node: Cross Compilation Tools, Next: Canadian Cross, Prev: Configuration Names, Up: Top
|
|
|
Cross Compilation Tools
|
Cross Compilation Tools
|
***********************
|
***********************
|
|
|
The GNU configure and build system can be used to build "cross
|
The GNU configure and build system can be used to build "cross
|
compilation" tools. A cross compilation tool is a tool which runs on
|
compilation" tools. A cross compilation tool is a tool which runs on
|
one system and produces code which runs on another system.
|
one system and produces code which runs on another system.
|
|
|
* Menu:
|
* Menu:
|
|
|
* Cross Compilation Concepts:: Cross Compilation Concepts.
|
* Cross Compilation Concepts:: Cross Compilation Concepts.
|
* Host and Target:: Host and Target.
|
* Host and Target:: Host and Target.
|
* Using the Host Type:: Using the Host Type.
|
* Using the Host Type:: Using the Host Type.
|
* Specifying the Target:: Specifying the Target.
|
* Specifying the Target:: Specifying the Target.
|
* Using the Target Type:: Using the Target Type.
|
* Using the Target Type:: Using the Target Type.
|
* Cross Tools in the Cygnus Tree:: Cross Tools in the Cygnus Tree
|
* Cross Tools in the Cygnus Tree:: Cross Tools in the Cygnus Tree
|
|
|
|
|
File: configure.info, Node: Cross Compilation Concepts, Next: Host and Target, Up: Cross Compilation Tools
|
File: configure.info, Node: Cross Compilation Concepts, Next: Host and Target, Up: Cross Compilation Tools
|
|
|
Cross Compilation Concepts
|
Cross Compilation Concepts
|
==========================
|
==========================
|
|
|
A compiler which produces programs which run on a different system
|
A compiler which produces programs which run on a different system
|
is a cross compilation compiler, or simply a "cross compiler".
|
is a cross compilation compiler, or simply a "cross compiler".
|
Similarly, we speak of cross assemblers, cross linkers, etc.
|
Similarly, we speak of cross assemblers, cross linkers, etc.
|
|
|
In the normal case, a compiler produces code which runs on the same
|
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
|
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
|
distinguish this case from the cross compilation case, such a compiler
|
is called a "native compiler". Similarly, we speak of native
|
is called a "native compiler". Similarly, we speak of native
|
assemblers, etc.
|
assemblers, etc.
|
|
|
Although the debugger is not strictly speaking a compilation tool,
|
Although the debugger is not strictly speaking a compilation tool,
|
it is nevertheless meaningful to speak of a cross debugger: a debugger
|
it is nevertheless meaningful to speak of a cross debugger: a debugger
|
which is used to debug code which runs on another system. Everything
|
which is used to debug code which runs on another system. Everything
|
that is said below about configuring cross compilation tools applies to
|
that is said below about configuring cross compilation tools applies to
|
the debugger as well.
|
the debugger as well.
|
|
|
|
|
File: configure.info, Node: Host and Target, Next: Using the Host Type, Prev: Cross Compilation Concepts, Up: Cross Compilation Tools
|
File: configure.info, Node: Host and Target, Next: Using the Host Type, Prev: Cross Compilation Concepts, Up: Cross Compilation Tools
|
|
|
Host and Target
|
Host and Target
|
===============
|
===============
|
|
|
When building cross compilation tools, there are two different
|
When building cross compilation tools, there are two different
|
systems involved: the system on which the tools will run, and the
|
systems involved: the system on which the tools will run, and the
|
system for which the tools generate code.
|
system for which the tools generate code.
|
|
|
The system on which the tools will run is called the "host" system.
|
The system on which the tools will run is called the "host" system.
|
|
|
The system for which the tools generate code is called the "target"
|
The system for which the tools generate code is called the "target"
|
system.
|
system.
|
|
|
For example, suppose you have a compiler which runs on a GNU/Linux
|
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
|
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
|
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
|
target. Such a compiler could be called a GNU/Linux cross MIPS ELF
|
compiler, or, equivalently, a `i386-linux-gnu' cross `mips-elf'
|
compiler, or, equivalently, a `i386-linux-gnu' cross `mips-elf'
|
compiler.
|
compiler.
|
|
|
Naturally, most programs are not cross compilation tools. For those
|
Naturally, most programs are not cross compilation tools. For those
|
programs, it does not make sense to speak of a target. It only makes
|
programs, it does not make sense to speak of a target. It only makes
|
sense to speak of a target for tools like `gcc' or the `binutils' which
|
sense to speak of a target for tools like `gcc' or the `binutils' which
|
actually produce running code. For example, it does not make sense to
|
actually produce running code. For example, it does not make sense to
|
speak of the target of a tool like `bison' or `make'.
|
speak of the target of a tool like `bison' or `make'.
|
|
|
Most cross compilation tools can also serve as native tools. For a
|
Most cross compilation tools can also serve as native tools. For a
|
native compilation tool, it is still meaningful to speak of a target.
|
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
|
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
|
a GNU/Linux native compiler, the host is GNU/Linux, and the target is
|
also GNU/Linux.
|
also GNU/Linux.
|
|
|
|
|
File: configure.info, Node: Using the Host Type, Next: Specifying the Target, Prev: Host and Target, Up: Cross Compilation Tools
|
File: configure.info, Node: Using the Host Type, Next: Specifying the Target, Prev: Host and Target, Up: Cross Compilation Tools
|
|
|
Using the Host Type
|
Using the Host Type
|
===================
|
===================
|
|
|
In almost all cases the host system is the system on which you run
|
In almost all cases the host system is the system on which you run
|
the `configure' script, and on which you build the tools (for the case
|
the `configure' script, and on which you build the tools (for the case
|
when they differ, *note Canadian Cross::).
|
when they differ, *note Canadian Cross::).
|
|
|
If your configure script needs to know the configuration name of the
|
If your configure script needs to know the configuration name of the
|
host system, and the package is not a cross compilation tool and
|
host system, and the package is not a cross compilation tool and
|
therefore does not have a target, put `AC_CANONICAL_HOST' in
|
therefore does not have a target, put `AC_CANONICAL_HOST' in
|
`configure.in'. This macro will arrange to define a few shell
|
`configure.in'. This macro will arrange to define a few shell
|
variables when the `configure' script is run.
|
variables when the `configure' script is run.
|
|
|
`host'
|
`host'
|
The canonical configuration name of the host. This will normally
|
The canonical configuration name of the host. This will normally
|
be determined by running the `config.guess' shell script, although
|
be determined by running the `config.guess' shell script, although
|
the user is permitted to override this by using an explicit
|
the user is permitted to override this by using an explicit
|
`--host' option.
|
`--host' option.
|
|
|
`host_alias'
|
`host_alias'
|
In the unusual case that the user used an explicit `--host' option,
|
In the unusual case that the user used an explicit `--host' option,
|
this will be the argument to `--host'. In the normal case, this
|
this will be the argument to `--host'. In the normal case, this
|
will be the same as the `host' variable.
|
will be the same as the `host' variable.
|
|
|
`host_cpu'
|
`host_cpu'
|
`host_vendor'
|
`host_vendor'
|
`host_os'
|
`host_os'
|
The first three parts of the canonical configuration name.
|
The first three parts of the canonical configuration name.
|
|
|
The shell variables may be used by putting shell code in
|
The shell variables may be used by putting shell code in
|
`configure.in'. For an example, see *Note Using Configuration Names::.
|
`configure.in'. For an example, see *Note Using Configuration Names::.
|
|
|
|
|
File: configure.info, Node: Specifying the Target, Next: Using the Target Type, Prev: Using the Host Type, Up: Cross Compilation Tools
|
File: configure.info, Node: Specifying the Target, Next: Using the Target Type, Prev: Using the Host Type, Up: Cross Compilation Tools
|
|
|
Specifying the Target
|
Specifying the Target
|
=====================
|
=====================
|
|
|
By default, the `configure' script will assume that the target is
|
By default, the `configure' script will assume that the target is
|
the same as the host. This is the more common case; for example, it
|
the same as the host. This is the more common case; for example, it
|
leads to a native compiler rather than a cross compiler.
|
leads to a native compiler rather than a cross compiler.
|
|
|
If you want to build a cross compilation tool, you must specify the
|
If you want to build a cross compilation tool, you must specify the
|
target explicitly by using the `--target' option when you run
|
target explicitly by using the `--target' option when you run
|
`configure'. The argument to `--target' is the configuration name of
|
`configure'. The argument to `--target' is the configuration name of
|
the system for which you wish to generate code. *Note Configuration
|
the system for which you wish to generate code. *Note Configuration
|
Names::.
|
Names::.
|
|
|
For example, to build tools which generate code for a MIPS ELF
|
For example, to build tools which generate code for a MIPS ELF
|
embedded system, you would use `--target mips-elf'.
|
embedded system, you would use `--target mips-elf'.
|
|
|
|
|
File: configure.info, Node: Using the Target Type, Next: Cross Tools in the Cygnus Tree, Prev: Specifying the Target, Up: Cross Compilation Tools
|
File: configure.info, Node: Using the Target Type, Next: Cross Tools in the Cygnus Tree, Prev: Specifying the Target, Up: Cross Compilation Tools
|
|
|
Using the Target Type
|
Using the Target Type
|
=====================
|
=====================
|
|
|
When writing `configure.in' for a cross compilation tool, you will
|
When writing `configure.in' for a cross compilation tool, you will
|
need to use information about the target. To do this, put
|
need to use information about the target. To do this, put
|
`AC_CANONICAL_SYSTEM' in `configure.in'.
|
`AC_CANONICAL_SYSTEM' in `configure.in'.
|
|
|
`AC_CANONICAL_SYSTEM' will look for a `--target' option and
|
`AC_CANONICAL_SYSTEM' will look for a `--target' option and
|
canonicalize it using the `config.sub' shell script. It will also run
|
canonicalize it using the `config.sub' shell script. It will also run
|
`AC_CANONICAL_HOST' (*note Using the Host Type::).
|
`AC_CANONICAL_HOST' (*note Using the Host Type::).
|
|
|
The target type will be recorded in the following shell variables.
|
The target type will be recorded in the following shell variables.
|
Note that the host versions of these variables will also be defined by
|
Note that the host versions of these variables will also be defined by
|
`AC_CANONICAL_HOST'.
|
`AC_CANONICAL_HOST'.
|
|
|
`target'
|
`target'
|
The canonical configuration name of the target.
|
The canonical configuration name of the target.
|
|
|
`target_alias'
|
`target_alias'
|
The argument to the `--target' option. If the user did not specify
|
The argument to the `--target' option. If the user did not specify
|
a `--target' option, this will be the same as `host_alias'.
|
a `--target' option, this will be the same as `host_alias'.
|
|
|
`target_cpu'
|
`target_cpu'
|
`target_vendor'
|
`target_vendor'
|
`target_os'
|
`target_os'
|
The first three parts of the canonical target configuration name.
|
The first three parts of the canonical target configuration name.
|
|
|
Note that if `host' and `target' are the same string, you can assume
|
Note that if `host' and `target' are the same string, you can assume
|
a native configuration. If they are different, you can assume a cross
|
a native configuration. If they are different, you can assume a cross
|
configuration.
|
configuration.
|
|
|
It is arguably possible for `host' and `target' to represent the
|
It is arguably possible for `host' and `target' to represent the
|
same system, but for the strings to not be identical. For example, if
|
same system, but for the strings to not be identical. For example, if
|
`config.guess' returns `sparc-sun-sunos4.1.4', and somebody configures
|
`config.guess' returns `sparc-sun-sunos4.1.4', and somebody configures
|
with `--target sparc-sun-sunos4.1', then the slight differences between
|
with `--target sparc-sun-sunos4.1', then the slight differences between
|
the two versions of SunOS may be unimportant for your tool. However,
|
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
|
in the general case it can be quite difficult to determine whether the
|
differences between two configuration names are significant or not.
|
differences between two configuration names are significant or not.
|
Therefore, by convention, if the user specifies a `--target' option
|
Therefore, by convention, if the user specifies a `--target' option
|
without specifying a `--host' option, it is assumed that the user wants
|
without specifying a `--host' option, it is assumed that the user wants
|
to configure a cross compilation tool.
|
to configure a cross compilation tool.
|
|
|
The variables `target' and `target_alias' should be handled
|
The variables `target' and `target_alias' should be handled
|
differently.
|
differently.
|
|
|
In general, whenever the user may actually see a string,
|
In general, whenever the user may actually see a string,
|
`target_alias' should be used. This includes anything which may appear
|
`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.
|
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
|
It also includes any tool output, unless it is clearly labelled as the
|
canonical target configuration name. This permits the user to use the
|
canonical target configuration name. This permits the user to use the
|
`--target' option to specify how the tool will appear to the outside
|
`--target' option to specify how the tool will appear to the outside
|
world.
|
world.
|
|
|
On the other hand, when checking for characteristics of the target
|
On the other hand, when checking for characteristics of the target
|
system, `target' should be used. This is because a wide variety of
|
system, `target' should be used. This is because a wide variety of
|
`--target' options may map into the same canonical configuration name.
|
`--target' options may map into the same canonical configuration name.
|
You should not attempt to duplicate the canonicalization done by
|
You should not attempt to duplicate the canonicalization done by
|
`config.sub' in your own code.
|
`config.sub' in your own code.
|
|
|
By convention, cross tools are installed with a prefix of the
|
By convention, cross tools are installed with a prefix of the
|
argument used with the `--target' option, also known as `target_alias'
|
argument used with the `--target' option, also known as `target_alias'
|
(*note Using the Target Type::). If the user does not use the
|
(*note Using the Target Type::). If the user does not use the
|
`--target' option, and thus is building a native tool, no prefix is
|
`--target' option, and thus is building a native tool, no prefix is
|
used.
|
used.
|
|
|
For example, if gcc is configured with `--target mips-elf', then the
|
For example, if gcc is configured with `--target mips-elf', then the
|
installed binary will be named `mips-elf-gcc'. If gcc is configured
|
installed binary will be named `mips-elf-gcc'. If gcc is configured
|
without a `--target' option, then the installed binary will be named
|
without a `--target' option, then the installed binary will be named
|
`gcc'.
|
`gcc'.
|
|
|
The autoconf macro `AC_ARG_PROGRAM' will handle this for you. If
|
The autoconf macro `AC_ARG_PROGRAM' will handle this for you. If
|
you are using automake, no more need be done; the programs will
|
you are using automake, no more need be done; the programs will
|
automatically be installed with the correct prefixes. Otherwise, see
|
automatically be installed with the correct prefixes. Otherwise, see
|
the autoconf documentation for `AC_ARG_PROGRAM'.
|
the autoconf documentation for `AC_ARG_PROGRAM'.
|
|
|
|
|
File: configure.info, Node: Cross Tools in the Cygnus Tree, Prev: Using the Target Type, Up: Cross Compilation Tools
|
File: configure.info, Node: Cross Tools in the Cygnus Tree, Prev: Using the Target Type, Up: Cross Compilation Tools
|
|
|
Cross Tools in the Cygnus Tree
|
Cross Tools in the Cygnus Tree
|
==============================
|
==============================
|
|
|
The Cygnus tree is used for various packages including gdb, the GNU
|
The Cygnus tree is used for various packages including gdb, the GNU
|
binutils, and egcs. It is also, of course, used for Cygnus releases.
|
binutils, and egcs. It is also, of course, used for Cygnus releases.
|
|
|
In the Cygnus tree, the top level `configure' script uses the old
|
In the Cygnus tree, the top level `configure' script uses the old
|
Cygnus configure system, not autoconf. The top level `Makefile.in' is
|
Cygnus configure system, not autoconf. The top level `Makefile.in' is
|
written to build packages based on what is in the source tree, and
|
written to build packages based on what is in the source tree, and
|
supports building a large number of tools in a single
|
supports building a large number of tools in a single
|
`configure'/`make' step.
|
`configure'/`make' step.
|
|
|
The Cygnus tree may be configured with a `--target' option. The
|
The Cygnus tree may be configured with a `--target' option. The
|
`--target' option applies recursively to every subdirectory, and
|
`--target' option applies recursively to every subdirectory, and
|
permits building an entire set of cross tools at once.
|
permits building an entire set of cross tools at once.
|
|
|
* Menu:
|
* Menu:
|
|
|
* Host and Target Libraries:: Host and Target Libraries.
|
* Host and Target Libraries:: Host and Target Libraries.
|
* Target Library Configure Scripts:: Target Library Configure Scripts.
|
* Target Library Configure Scripts:: Target Library Configure Scripts.
|
* Make Targets in Cygnus Tree:: Make Targets in Cygnus Tree.
|
* Make Targets in Cygnus Tree:: Make Targets in Cygnus Tree.
|
* Target libiberty:: Target libiberty
|
* Target libiberty:: Target libiberty
|
|
|
|
|
File: configure.info, Node: Host and Target Libraries, Next: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
|
File: configure.info, Node: Host and Target Libraries, Next: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
|
|
|
Host and Target Libraries
|
Host and Target Libraries
|
-------------------------
|
-------------------------
|
|
|
The Cygnus tree distinguishes host libraries from target libraries.
|
The Cygnus tree distinguishes host libraries from target libraries.
|
|
|
Host libraries are built with the compiler used to build the programs
|
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
|
which run on the host, which is called the host compiler. This includes
|
libraries such as `bfd' and `tcl'. These libraries are built with the
|
libraries such as `bfd' and `tcl'. These libraries are built with the
|
host compiler, and are linked into programs like the binutils or gcc
|
host compiler, and are linked into programs like the binutils or gcc
|
which run on the host.
|
which run on the host.
|
|
|
Target libraries are built with the target compiler. If gcc is
|
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
|
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
|
built using the host compiler. Target libraries are libraries such as
|
`newlib' and `libstdc++'. These libraries are not linked into the host
|
`newlib' and `libstdc++'. These libraries are not linked into the host
|
programs, but are instead made available for use with programs built
|
programs, but are instead made available for use with programs built
|
with the target compiler.
|
with the target compiler.
|
|
|
For the rest of this section, assume that gcc is present in the
|
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.
|
source tree, so that it will be used to build the target libraries.
|
|
|
There is a complication here. The configure process needs to know
|
There is a complication here. The configure process needs to know
|
which compiler you are going to use to build a tool; otherwise, the
|
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
|
feature tests will not work correctly. The Cygnus tree handles this by
|
not configuring the target libraries until the target compiler is
|
not configuring the target libraries until the target compiler is
|
built. In order to permit everything to build using a single
|
built. In order to permit everything to build using a single
|
`configure'/`make', the configuration of the target libraries is
|
`configure'/`make', the configuration of the target libraries is
|
actually triggered during the make step.
|
actually triggered during the make step.
|
|
|
When the target libraries are configured, the `--target' option is
|
When the target libraries are configured, the `--target' option is
|
not used. Instead, the `--host' option is used with the argument of
|
not used. Instead, the `--host' option is used with the argument of
|
the `--target' option for the overall configuration. If no `--target'
|
the `--target' option for the overall configuration. If no `--target'
|
option was used for the overall configuration, the `--host' option will
|
option was used for the overall configuration, the `--host' option will
|
be passed with the output of the `config.guess' shell script. Any
|
be passed with the output of the `config.guess' shell script. Any
|
`--build' option is passed down unchanged.
|
`--build' option is passed down unchanged.
|
|
|
This translation of configuration options is done because since the
|
This translation of configuration options is done because since the
|
target libraries are compiled with the target compiler, they are being
|
target libraries are compiled with the target compiler, they are being
|
built in order to run on the target of the overall configuration. By
|
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 definition of host, this means that their host system is the same as
|
the target system of the overall configuration.
|
the target system of the overall configuration.
|
|
|
The same process is used for both a native configuration and a cross
|
The same process is used for both a native configuration and a cross
|
configuration. Even when using a native configuration, the target
|
configuration. Even when using a native configuration, the target
|
libraries will be configured and built using the newly built compiler.
|
libraries will be configured and built using the newly built compiler.
|
This is particularly important for the C++ libraries, since there is no
|
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
|
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++ compiler which will be
|
there even is one) uses the same ABI as the g++ compiler which will be
|
used to build the target libraries.
|
used to build the target libraries.
|
|
|
There is one difference between a native configuration and a cross
|
There is one difference between a native configuration and a cross
|
configuration. In a native configuration, the target libraries are
|
configuration. In a native configuration, the target libraries are
|
normally configured and built as siblings of the host tools. In a cross
|
normally configured and built as siblings of the host tools. In a cross
|
configuration, the target libraries are normally built in a subdirectory
|
configuration, the target libraries are normally built in a subdirectory
|
whose name is the argument to `--target'. This is mainly for
|
whose name is the argument to `--target'. This is mainly for
|
historical reasons.
|
historical reasons.
|
|
|
To summarize, running `configure' in the Cygnus tree configures all
|
To summarize, running `configure' in the Cygnus tree configures all
|
the host libraries and tools, but does not configure any of the target
|
the host libraries and tools, but does not configure any of the target
|
libraries. Running `make' then does the following steps:
|
libraries. Running `make' then does the following steps:
|
|
|
* Build the host libraries.
|
* Build the host libraries.
|
|
|
* Build the host programs, including gcc. Note that we call gcc
|
* Build the host programs, including gcc. Note that we call gcc
|
both a host program (since it runs on the host) and a target
|
both a host program (since it runs on the host) and a target
|
compiler (since it generates code for the target).
|
compiler (since it generates code for the target).
|
|
|
* Using the newly built target compiler, configure the target
|
* Using the newly built target compiler, configure the target
|
libraries.
|
libraries.
|
|
|
* Build the target libraries.
|
* Build the target libraries.
|
|
|
The steps need not be done in precisely this order, since they are
|
The steps need not be done in precisely this order, since they are
|
actually controlled by `Makefile' targets.
|
actually controlled by `Makefile' targets.
|
|
|
|
|
File: configure.info, Node: Target Library Configure Scripts, Next: Make Targets in Cygnus Tree, Prev: Host and Target Libraries, Up: Cross Tools in the Cygnus Tree
|
File: configure.info, Node: Target Library Configure Scripts, Next: Make Targets in Cygnus Tree, Prev: Host and Target Libraries, Up: Cross Tools in the Cygnus Tree
|
|
|
Target Library Configure Scripts
|
Target Library Configure Scripts
|
--------------------------------
|
--------------------------------
|
|
|
There are a few things you must know in order to write a configure
|
There are a few things you must know in order to write a configure
|
script for a target library. This is just a quick sketch, and beginners
|
script for a target library. This is just a quick sketch, and beginners
|
shouldn't worry if they don't follow everything here.
|
shouldn't worry if they don't follow everything here.
|
|
|
The target libraries are configured and built using a newly built
|
The target libraries are configured and built using a newly built
|
target compiler. There may not be any startup files or libraries for
|
target compiler. There may not be any startup files or libraries for
|
this target compiler. In fact, those files will probably be built as
|
this target compiler. In fact, those files will probably be built as
|
part of some target library, which naturally means that they will not
|
part of some target library, which naturally means that they will not
|
exist when your target library is configured.
|
exist when your target library is configured.
|
|
|
This means that the configure script for a target library may not use
|
This means that the configure script for a target library may not use
|
any test which requires doing a link. This unfortunately includes many
|
any test which requires doing a link. This unfortunately includes many
|
useful autoconf macros, such as `AC_CHECK_FUNCS'. autoconf macros
|
useful autoconf macros, such as `AC_CHECK_FUNCS'. autoconf macros
|
which do a compile but not a link, such as `AC_CHECK_HEADERS', may be
|
which do a compile but not a link, such as `AC_CHECK_HEADERS', may be
|
used.
|
used.
|
|
|
This is a severe restriction, but normally not a fatal one, as target
|
This is a severe restriction, but normally not a fatal one, as target
|
libraries can often assume the presence of other target libraries, and
|
libraries can often assume the presence of other target libraries, and
|
thus know which functions will be available.
|
thus know which functions will be available.
|
|
|
As of this writing, the autoconf macro `AC_PROG_CC' does a link to
|
As of this writing, the autoconf macro `AC_PROG_CC' does a link to
|
make sure that the compiler works. This may fail in a target library,
|
make sure that the compiler works. This may fail in a target library,
|
so target libraries must use a different set of macros to locate the
|
so target libraries must use a different set of macros to locate the
|
compiler. See the `configure.in' file in a directory like `libiberty'
|
compiler. See the `configure.in' file in a directory like `libiberty'
|
or `libgloss' for an example.
|
or `libgloss' for an example.
|
|
|
As noted in the previous section, target libraries are sometimes
|
As noted in the previous section, target libraries are sometimes
|
built in directories which are siblings to the host tools, and are
|
built in directories which are siblings to the host tools, and are
|
sometimes built in a subdirectory. The `--with-target-subdir' configure
|
sometimes built in a subdirectory. The `--with-target-subdir' configure
|
option will be passed when the library is configured. Its value will be
|
option will be passed when the library is configured. Its value will be
|
an empty string if the target library is a sibling. Its value will be
|
an empty string if the target library is a sibling. Its value will be
|
the name of the subdirectory if the target library is in a subdirectory.
|
the name of the subdirectory if the target library is in a subdirectory.
|
|
|
If the overall build is not a native build (i.e., the overall
|
If the overall build is not a native build (i.e., the overall
|
configure used the `--target' option), then the library will be
|
configure used the `--target' option), then the library will be
|
configured with the `--with-cross-host' option. The value of this
|
configured with the `--with-cross-host' option. The value of this
|
option will be the host system of the overall build. Recall that the
|
option will be the host system of the overall build. Recall that the
|
host system of the library will be the target of the overall build. If
|
host system of the library will be the target of the overall build. If
|
the overall build is a native build, the `--with-cross-host' option
|
the overall build is a native build, the `--with-cross-host' option
|
will not be used.
|
will not be used.
|
|
|
A library which can be built both standalone and as a target library
|
A library which can be built both standalone and as a target library
|
may want to install itself into different directories depending upon the
|
may want to install itself into different directories depending upon the
|
case. When built standalone, or when built native, the library should
|
case. When built standalone, or when built native, the library should
|
be installed in `$(libdir)'. When built as a target library which is
|
be installed in `$(libdir)'. When built as a target library which is
|
not native, the library should be installed in `$(tooldir)/lib'. The
|
not native, the library should be installed in `$(tooldir)/lib'. The
|
`--with-cross-host' option may be used to distinguish these cases.
|
`--with-cross-host' option may be used to distinguish these cases.
|
|
|
This same test of `--with-cross-host' may be used to see whether it
|
This same test of `--with-cross-host' may be used to see whether it
|
is OK to use link tests in the configure script. If the
|
is OK to use link tests in the configure script. If the
|
`--with-cross-host' option is not used, then the library is being built
|
`--with-cross-host' option is not used, then the library is being built
|
either standalone or native, and a link should work.
|
either standalone or native, and a link should work.
|
|
|
|
|
File: configure.info, Node: Make Targets in Cygnus Tree, Next: Target libiberty, Prev: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
|
File: configure.info, Node: Make Targets in Cygnus Tree, Next: Target libiberty, Prev: Target Library Configure Scripts, Up: Cross Tools in the Cygnus Tree
|
|
|
Make Targets in Cygnus Tree
|
Make Targets in Cygnus Tree
|
---------------------------
|
---------------------------
|
|
|
The top level `Makefile' in the Cygnus tree defines targets for
|
The top level `Makefile' in the Cygnus tree defines targets for
|
every known subdirectory.
|
every known subdirectory.
|
|
|
For every subdirectory DIR which holds a host library or program,
|
For every subdirectory DIR which holds a host library or program,
|
the `Makefile' target `all-DIR' will build that library or program.
|
the `Makefile' target `all-DIR' will build that library or program.
|
|
|
There are dependencies among host tools. For example, building gcc
|
There are dependencies among host tools. For example, building gcc
|
requires first building gas, because the gcc build process invokes the
|
requires first building gas, because the gcc build process invokes the
|
target assembler. These dependencies are reflected in the top level
|
target assembler. These dependencies are reflected in the top level
|
`Makefile'.
|
`Makefile'.
|
|
|
For every subdirectory DIR which holds a target library, the
|
For every subdirectory DIR which holds a target library, the
|
`Makefile' target `configure-target-DIR' will configure that library.
|
`Makefile' target `configure-target-DIR' will configure that library.
|
The `Makefile' target `all-target-DIR' will build that library.
|
The `Makefile' target `all-target-DIR' will build that library.
|
|
|
Every `configure-target-DIR' target depends upon `all-gcc', since
|
Every `configure-target-DIR' target depends upon `all-gcc', since
|
gcc, the target compiler, is required to configure the tool. Every
|
gcc, the target compiler, is required to configure the tool. Every
|
`all-target-DIR' target depends upon the corresponding
|
`all-target-DIR' target depends upon the corresponding
|
`configure-target-DIR' target.
|
`configure-target-DIR' target.
|
|
|
There are several other targets which may be of interest for each
|
There are several other targets which may be of interest for each
|
directory: `install-DIR', `clean-DIR', and `check-DIR'. There are also
|
directory: `install-DIR', `clean-DIR', and `check-DIR'. There are also
|
corresponding `target' versions of these for the target libraries ,
|
corresponding `target' versions of these for the target libraries ,
|
such as `install-target-DIR'.
|
such as `install-target-DIR'.
|
|
|
|
|
File: configure.info, Node: Target libiberty, Prev: Make Targets in Cygnus Tree, Up: Cross Tools in the Cygnus Tree
|
File: configure.info, Node: Target libiberty, Prev: Make Targets in Cygnus Tree, Up: Cross Tools in the Cygnus Tree
|
|
|
Target libiberty
|
Target libiberty
|
----------------
|
----------------
|
|
|
The `libiberty' subdirectory is currently a special case, in that it
|
The `libiberty' subdirectory is currently a special case, in that it
|
is the only directory which is built both using the host compiler and
|
is the only directory which is built both using the host compiler and
|
using the target compiler.
|
using the target compiler.
|
|
|
This is because the files in `libiberty' are used when building the
|
This is because the files in `libiberty' are used when building the
|
host tools, and they are also incorporated into the `libstdc++' target
|
host tools, and they are also incorporated into the `libstdc++' target
|
library as support code.
|
library as support code.
|
|
|
This duality does not pose any particular difficulties. It means
|
This duality does not pose any particular difficulties. It means
|
that there are targets for both `all-libiberty' and
|
that there are targets for both `all-libiberty' and
|
`all-target-libiberty'.
|
`all-target-libiberty'.
|
|
|
In a native configuration, when target libraries are not built in a
|
In a native configuration, when target libraries are not built in a
|
subdirectory, the same objects are normally used as both the host build
|
subdirectory, the same objects are normally used as both the host build
|
and the target build. This is normally OK, since libiberty contains
|
and the target build. This is normally OK, since libiberty contains
|
only C code, and in a native configuration the results of the host
|
only C code, and in a native configuration the results of the host
|
compiler and the target compiler are normally interoperable.
|
compiler and the target compiler are normally interoperable.
|
|
|
Irix 6 is again an exception here, since the SGI native compiler
|
Irix 6 is again an exception here, since the SGI native compiler
|
defaults to using the `O32' ABI, and gcc defaults to using the `N32'
|
defaults to using the `O32' ABI, and gcc defaults to using the `N32'
|
ABI. On Irix 6, the target libraries are built in a subdirectory even
|
ABI. On Irix 6, the target libraries are built in a subdirectory even
|
for a native configuration, avoiding this problem.
|
for a native configuration, avoiding this problem.
|
|
|
There are currently no other libraries built for both the host and
|
There are currently no other libraries built for both the host and
|
the target, but there is no conceptual problem with adding more.
|
the target, but there is no conceptual problem with adding more.
|
|
|
|
|
File: configure.info, Node: Canadian Cross, Next: Cygnus Configure, Prev: Cross Compilation Tools, Up: Top
|
File: configure.info, Node: Canadian Cross, Next: Cygnus Configure, Prev: Cross Compilation Tools, Up: Top
|
|
|
Canadian Cross
|
Canadian Cross
|
**************
|
**************
|
|
|
It is possible to use the GNU configure and build system to build a
|
It is possible to use the GNU configure and build system to build a
|
program which will run on a system which is different from the system on
|
program which will run on a system which is different from the system on
|
which the tools are built. In other words, it is possible to build
|
which the tools are built. In other words, it is possible to build
|
programs using a cross compiler.
|
programs using a cross compiler.
|
|
|
This is referred to as a "Canadian Cross".
|
This is referred to as a "Canadian Cross".
|
|
|
* Menu:
|
* Menu:
|
|
|
* Canadian Cross Example:: Canadian Cross Example.
|
* Canadian Cross Example:: Canadian Cross Example.
|
* Canadian Cross Concepts:: Canadian Cross Concepts.
|
* Canadian Cross Concepts:: Canadian Cross Concepts.
|
* Build Cross Host Tools:: Build Cross Host Tools.
|
* Build Cross Host Tools:: Build Cross Host Tools.
|
* Build and Host Options:: Build and Host Options.
|
* Build and Host Options:: Build and Host Options.
|
* CCross not in Cygnus Tree:: Canadian Cross not in Cygnus Tree.
|
* CCross not in Cygnus Tree:: Canadian Cross not in Cygnus Tree.
|
* CCross in Cygnus Tree:: Canadian Cross in Cygnus Tree.
|
* CCross in Cygnus Tree:: Canadian Cross in Cygnus Tree.
|
* Supporting Canadian Cross:: Supporting Canadian Cross.
|
* Supporting Canadian Cross:: Supporting Canadian Cross.
|
|
|
|
|
File: configure.info, Node: Canadian Cross Example, Next: Canadian Cross Concepts, Up: Canadian Cross
|
File: configure.info, Node: Canadian Cross Example, Next: Canadian Cross Concepts, Up: Canadian Cross
|
|
|
Canadian Cross Example
|
Canadian Cross Example
|
======================
|
======================
|
|
|
Here is an example of a Canadian Cross.
|
Here is an example of a Canadian Cross.
|
|
|
While running on a GNU/Linux, you can build a program which will run
|
While running on a GNU/Linux, you can build a program which will run
|
on a Solaris system. You would use a GNU/Linux cross Solaris compiler
|
on a Solaris system. You would use a GNU/Linux cross Solaris compiler
|
to build the program.
|
to build the program.
|
|
|
Of course, you could not run the resulting program on your GNU/Linux
|
Of course, you could not run the resulting program on your GNU/Linux
|
system. You would have to copy it over to a Solaris system before you
|
system. You would have to copy it over to a Solaris system before you
|
would run it.
|
would run it.
|
|
|
Of course, you could also simply build the programs on the Solaris
|
Of course, you could also simply build the programs on the Solaris
|
system in the first place. However, perhaps the Solaris system is not
|
system in the first place. However, perhaps the Solaris system is not
|
available for some reason; perhaps you actually don't have one, but you
|
available for some reason; perhaps you actually don't have one, but you
|
want to build the tools for somebody else to use. Or perhaps your
|
want to build the tools for somebody else to use. Or perhaps your
|
GNU/Linux system is much faster than your Solaris system.
|
GNU/Linux system is much faster than your Solaris system.
|
|
|
A Canadian Cross build is most frequently used when building
|
A Canadian Cross build is most frequently used when building
|
programs to run on a non-Unix system, such as DOS or Windows. It may
|
programs to run on a non-Unix system, such as DOS or Windows. It may
|
be simpler to configure and build on a Unix system than to support the
|
be simpler to configure and build on a Unix system than to support the
|
configuration machinery on a non-Unix system.
|
configuration machinery on a non-Unix system.
|
|
|
|
|
File: configure.info, Node: Canadian Cross Concepts, Next: Build Cross Host Tools, Prev: Canadian Cross Example, Up: Canadian Cross
|
File: configure.info, Node: Canadian Cross Concepts, Next: Build Cross Host Tools, Prev: Canadian Cross Example, Up: Canadian Cross
|
|
|
Canadian Cross Concepts
|
Canadian Cross Concepts
|
=======================
|
=======================
|
|
|
When building a Canadian Cross, there are at least two different
|
When building a Canadian Cross, there are at least two different
|
systems involved: the system on which the tools are being built, and
|
systems involved: the system on which the tools are being built, and
|
the system on which the tools will run.
|
the system on which the tools will run.
|
|
|
The system on which the tools are being built is called the "build"
|
The system on which the tools are being built is called the "build"
|
system.
|
system.
|
|
|
The system on which the tools will run is called the host system.
|
The system on which the tools will run is called the host system.
|
|
|
For example, if you are building a Solaris program on a GNU/Linux
|
For example, if you are building a Solaris program on a GNU/Linux
|
system, as in the previous section, the build system would be GNU/Linux,
|
system, as in the previous section, the build system would be GNU/Linux,
|
and the host system would be Solaris.
|
and the host system would be Solaris.
|
|
|
It is, of course, possible to build a cross compiler using a Canadian
|
It is, of course, possible to build a cross compiler using a Canadian
|
Cross (i.e., build a cross compiler using a cross compiler). In this
|
Cross (i.e., build a cross compiler using a cross compiler). In this
|
case, the system for which the resulting cross compiler generates code
|
case, the system for which the resulting cross compiler generates code
|
is called the target system. (For a more complete discussion of host
|
is called the target system. (For a more complete discussion of host
|
and target systems, *note Host and Target::).
|
and target systems, *note Host and Target::).
|
|
|
An example of building a cross compiler using a Canadian Cross would
|
An example of building a cross compiler using a Canadian Cross would
|
be building a Windows cross MIPS ELF compiler on a GNU/Linux system. In
|
be building a Windows cross MIPS ELF compiler on a GNU/Linux system. In
|
this case the build system would be GNU/Linux, the host system would be
|
this case the build system would be GNU/Linux, the host system would be
|
Windows, and the target system would be MIPS ELF.
|
Windows, and the target system would be MIPS ELF.
|
|
|
The name Canadian Cross comes from the case when the build, host, and
|
The name Canadian Cross comes from the case when the build, host, and
|
target systems are all different. At the time that these issues were
|
target systems are all different. At the time that these issues were
|
all being hashed out, Canada had three national political parties.
|
all being hashed out, Canada had three national political parties.
|
|
|
|
|
File: configure.info, Node: Build Cross Host Tools, Next: Build and Host Options, Prev: Canadian Cross Concepts, Up: Canadian Cross
|
File: configure.info, Node: Build Cross Host Tools, Next: Build and Host Options, Prev: Canadian Cross Concepts, Up: Canadian Cross
|
|
|
Build Cross Host Tools
|
Build Cross Host Tools
|
======================
|
======================
|
|
|
In order to configure a program for a Canadian Cross build, you must
|
In order to configure a program for a Canadian Cross build, you must
|
first build and install the set of cross tools you will use to build the
|
first build and install the set of cross tools you will use to build the
|
program.
|
program.
|
|
|
These tools will be build cross host tools. That is, they will run
|
These tools will be build cross host tools. That is, they will run
|
on the build system, and will produce code that runs on the host system.
|
on the build system, and will produce code that runs on the host system.
|
|
|
It is easy to confuse the meaning of build and host here. Always
|
It is easy to confuse the meaning of build and host here. Always
|
remember that the build system is where you are doing the build, and the
|
remember that the build system is where you are doing the build, and the
|
host system is where the resulting program will run. Therefore, you
|
host system is where the resulting program will run. Therefore, you
|
need a build cross host compiler.
|
need a build cross host compiler.
|
|
|
In general, you must have a complete cross environment in order to do
|
In general, you must have a complete cross environment in order to do
|
the build. This normally means a cross compiler, cross assembler, and
|
the build. This normally means a cross compiler, cross assembler, and
|
so forth, as well as libraries and include files for the host system.
|
so forth, as well as libraries and include files for the host system.
|
|
|
|
|
File: configure.info, Node: Build and Host Options, Next: CCross not in Cygnus Tree, Prev: Build Cross Host Tools, Up: Canadian Cross
|
File: configure.info, Node: Build and Host Options, Next: CCross not in Cygnus Tree, Prev: Build Cross Host Tools, Up: Canadian Cross
|
|
|
Build and Host Options
|
Build and Host Options
|
======================
|
======================
|
|
|
When you run `configure', you must use both the `--build' and
|
When you run `configure', you must use both the `--build' and
|
`--host' options.
|
`--host' options.
|
|
|
The `--build' option is used to specify the configuration name of
|
The `--build' option is used to specify the configuration name of
|
the build system. This can normally be the result of running the
|
the build system. This can normally be the result of running the
|
`config.guess' shell script, and it is reasonable to use
|
`config.guess' shell script, and it is reasonable to use
|
`--build=`config.guess`'.
|
`--build=`config.guess`'.
|
|
|
The `--host' option is used to specify the configuration name of the
|
The `--host' option is used to specify the configuration name of the
|
host system.
|
host system.
|
|
|
As we explained earlier, `config.guess' is used to set the default
|
As we explained earlier, `config.guess' is used to set the default
|
value for the `--host' option (*note Using the Host Type::). We can
|
value for the `--host' option (*note Using the Host Type::). We can
|
now see that since `config.guess' returns the type of system on which
|
now see that since `config.guess' returns the type of system on which
|
it is run, it really identifies the build system. Since the host
|
it is run, it really identifies the build system. Since the host
|
system is normally the same as the build system (i.e., people do not
|
system is normally the same as the build system (i.e., people do not
|
normally build using a cross compiler), it is reasonable to use the
|
normally build using a cross compiler), it is reasonable to use the
|
result of `config.guess' as the default for the host system when the
|
result of `config.guess' as the default for the host system when the
|
`--host' option is not used.
|
`--host' option is not used.
|
|
|
It might seem that if the `--host' option were used without the
|
It might seem that if the `--host' option were used without the
|
`--build' option that the configure script could run `config.guess' to
|
`--build' option that the configure script could run `config.guess' to
|
determine the build system, and presume a Canadian Cross if the result
|
determine the build system, and presume a Canadian Cross if the result
|
of `config.guess' differed from the `--host' option. However, for
|
of `config.guess' differed from the `--host' option. However, for
|
historical reasons, some configure scripts are routinely run using an
|
historical reasons, some configure scripts are routinely run using an
|
explicit `--host' option, rather than using the default from
|
explicit `--host' option, rather than using the default from
|
`config.guess'. As noted earlier, it is difficult or impossible to
|
`config.guess'. As noted earlier, it is difficult or impossible to
|
reliably compare configuration names (*note Using the Target Type::).
|
reliably compare configuration names (*note Using the Target Type::).
|
Therefore, by convention, if the `--host' option is used, but the
|
Therefore, by convention, if the `--host' option is used, but the
|
`--build' option is not used, then the build system defaults to the
|
`--build' option is not used, then the build system defaults to the
|
host system.
|
host system.
|
|
|
|
|
File: configure.info, Node: CCross not in Cygnus Tree, Next: CCross in Cygnus Tree, Prev: Build and Host Options, Up: Canadian Cross
|
File: configure.info, Node: CCross not in Cygnus Tree, Next: CCross in Cygnus Tree, Prev: Build and Host Options, Up: Canadian Cross
|
|
|
Canadian Cross not in Cygnus Tree.
|
Canadian Cross not in Cygnus Tree.
|
==================================
|
==================================
|
|
|
If you are not using the Cygnus tree, you must explicitly specify the
|
If you are not using the Cygnus tree, you must explicitly specify the
|
cross tools which you want to use to build the program. This is done by
|
cross tools which you want to use to build the program. This is done by
|
setting environment variables before running the `configure' script.
|
setting environment variables before running the `configure' script.
|
|
|
You must normally set at least the environment variables `CC', `AR',
|
You must normally set at least the environment variables `CC', `AR',
|
and `RANLIB' to the cross tools which you want to use to build.
|
and `RANLIB' to the cross tools which you want to use to build.
|
|
|
For some programs, you must set additional cross tools as well, such
|
For some programs, you must set additional cross tools as well, such
|
as `AS', `LD', or `NM'.
|
as `AS', `LD', or `NM'.
|
|
|
You would set these environment variables to the build cross tools
|
You would set these environment variables to the build cross tools
|
which you are going to use.
|
which you are going to use.
|
|
|
For example, if you are building a Solaris program on a GNU/Linux
|
For example, if you are building a Solaris program on a GNU/Linux
|
system, and your GNU/Linux cross Solaris compiler were named
|
system, and your GNU/Linux cross Solaris compiler were named
|
`solaris-gcc', then you would set the environment variable `CC' to
|
`solaris-gcc', then you would set the environment variable `CC' to
|
`solaris-gcc'.
|
`solaris-gcc'.
|
|
|
|
|
File: configure.info, Node: CCross in Cygnus Tree, Next: Supporting Canadian Cross, Prev: CCross not in Cygnus Tree, Up: Canadian Cross
|
File: configure.info, Node: CCross in Cygnus Tree, Next: Supporting Canadian Cross, Prev: CCross not in Cygnus Tree, Up: Canadian Cross
|
|
|
Canadian Cross in Cygnus Tree
|
Canadian Cross in Cygnus Tree
|
=============================
|
=============================
|
|
|
This section describes configuring and building a Canadian Cross when
|
This section describes configuring and building a Canadian Cross when
|
using the Cygnus tree.
|
using the Cygnus tree.
|
|
|
* Menu:
|
* Menu:
|
|
|
* Standard Cygnus CCross:: Building a Normal Program.
|
* Standard Cygnus CCross:: Building a Normal Program.
|
* Cross Cygnus CCross:: Building a Cross Program.
|
* Cross Cygnus CCross:: Building a Cross Program.
|
|
|
|
|
File: configure.info, Node: Standard Cygnus CCross, Next: Cross Cygnus CCross, Up: CCross in Cygnus Tree
|
File: configure.info, Node: Standard Cygnus CCross, Next: Cross Cygnus CCross, Up: CCross in Cygnus Tree
|
|
|
Building a Normal Program
|
Building a Normal Program
|
-------------------------
|
-------------------------
|
|
|
When configuring a Canadian Cross in the Cygnus tree, all the
|
When configuring a Canadian Cross in the Cygnus tree, all the
|
appropriate environment variables are automatically set to `HOST-TOOL',
|
appropriate environment variables are automatically set to `HOST-TOOL',
|
where HOST is the value used for the `--host' option, and TOOL is the
|
where HOST is the value used for the `--host' option, and TOOL is the
|
name of the tool (e.g., `gcc', `as', etc.). These tools must be on
|
name of the tool (e.g., `gcc', `as', etc.). These tools must be on
|
your `PATH'.
|
your `PATH'.
|
|
|
Adding a prefix of HOST will give the usual name for the build cross
|
Adding a prefix of HOST will give the usual name for the build cross
|
host tools. To see this, consider that when these cross tools were
|
host tools. To see this, consider that when these cross tools were
|
built, they were configured to run on the build system and to produce
|
built, they were configured to run on the build system and to produce
|
code for the host system. That is, they were configured with a
|
code for the host system. That is, they were configured with a
|
`--target' option that is the same as the system which we are now
|
`--target' option that is the same as the system which we are now
|
calling the host. Recall that the default name for installed cross
|
calling the host. Recall that the default name for installed cross
|
tools uses the target system as a prefix (*note Using the Target
|
tools uses the target system as a prefix (*note Using the Target
|
Type::). Since that is the system which we are now calling the host,
|
Type::). Since that is the system which we are now calling the host,
|
HOST is the right prefix to use.
|
HOST is the right prefix to use.
|
|
|
For example, if you configure with `--build=i386-linux-gnu' and
|
For example, if you configure with `--build=i386-linux-gnu' and
|
`--host=solaris', then the Cygnus tree will automatically default to
|
`--host=solaris', then the Cygnus tree will automatically default to
|
using the compiler `solaris-gcc'. You must have previously built and
|
using the compiler `solaris-gcc'. You must have previously built and
|
installed this compiler, probably by doing a build with no `--host'
|
installed this compiler, probably by doing a build with no `--host'
|
option and with a `--target' option of `solaris'.
|
option and with a `--target' option of `solaris'.
|
|
|
|
|
File: configure.info, Node: Cross Cygnus CCross, Prev: Standard Cygnus CCross, Up: CCross in Cygnus Tree
|
File: configure.info, Node: Cross Cygnus CCross, Prev: Standard Cygnus CCross, Up: CCross in Cygnus Tree
|
|
|
Building a Cross Program
|
Building a Cross Program
|
------------------------
|
------------------------
|
|
|
There are additional considerations if you want to build a cross
|
There are additional considerations if you want to build a cross
|
compiler, rather than a native compiler, in the Cygnus tree using a
|
compiler, rather than a native compiler, in the Cygnus tree using a
|
Canadian Cross.
|
Canadian Cross.
|
|
|
When you build a cross compiler using the Cygnus tree, then the
|
When you build a cross compiler using the Cygnus tree, then the
|
target libraries will normally be built with the newly built target
|
target libraries will normally be built with the newly built target
|
compiler (*note Host and Target Libraries::). However, this will not
|
compiler (*note Host and Target Libraries::). However, this will not
|
work when building with a Canadian Cross. This is because the newly
|
work when building with a Canadian Cross. This is because the newly
|
built target compiler will be a program which runs on the host system,
|
built target compiler will be a program which runs on the host system,
|
and therefore will not be able to run on the build system.
|
and therefore will not be able to run on the build system.
|
|
|
Therefore, when building a cross compiler with the Cygnus tree, you
|
Therefore, when building a cross compiler with the Cygnus tree, you
|
must first install a set of build cross target tools. These tools will
|
must first install a set of build cross target tools. These tools will
|
be used when building the target libraries.
|
be used when building the target libraries.
|
|
|
Note that this is not a requirement of a Canadian Cross in general.
|
Note that this is not a requirement of a Canadian Cross in general.
|
For example, it would be possible to build just the host cross target
|
For example, it would be possible to build just the host cross target
|
tools on the build system, to copy the tools to the host system, and to
|
tools on the build system, to copy the tools to the host system, and to
|
build the target libraries on the host system. The requirement for
|
build the target libraries on the host system. The requirement for
|
build cross target tools is imposed by the Cygnus tree, which expects
|
build cross target tools is imposed by the Cygnus tree, which expects
|
to be able to build both host programs and target libraries in a single
|
to be able to build both host programs and target libraries in a single
|
`configure'/`make' step. Because it builds these in a single step, it
|
`configure'/`make' step. Because it builds these in a single step, it
|
expects to be able to build the target libraries on the build system,
|
expects to be able to build the target libraries on the build system,
|
which means that it must use a build cross target toolchain.
|
which means that it must use a build cross target toolchain.
|
|
|
For example, suppose you want to build a Windows cross MIPS ELF
|
For example, suppose you want to build a Windows cross MIPS ELF
|
compiler on a GNU/Linux system. You must have previously installed
|
compiler on a GNU/Linux system. You must have previously installed
|
both a GNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELF
|
both a GNU/Linux cross Windows compiler and a GNU/Linux cross MIPS ELF
|
compiler.
|
compiler.
|
|
|
In order to build the Windows (configuration name `i386-cygwin32')
|
In order to build the Windows (configuration name `i386-cygwin32')
|
cross MIPS ELF (configure name `mips-elf') compiler, you might execute
|
cross MIPS ELF (configure name `mips-elf') compiler, you might execute
|
the following commands (long command lines are broken across lines with
|
the following commands (long command lines are broken across lines with
|
a trailing backslash as a continuation character).
|
a trailing backslash as a continuation character).
|
|
|
mkdir linux-x-cygwin32
|
mkdir linux-x-cygwin32
|
cd linux-x-cygwin32
|
cd linux-x-cygwin32
|
SRCDIR/configure --target i386-cygwin32 --prefix=INSTALLDIR \
|
SRCDIR/configure --target i386-cygwin32 --prefix=INSTALLDIR \
|
--exec-prefix=INSTALLDIR/H-i386-linux
|
--exec-prefix=INSTALLDIR/H-i386-linux
|
make
|
make
|
make install
|
make install
|
cd ..
|
cd ..
|
mkdir linux-x-mips-elf
|
mkdir linux-x-mips-elf
|
cd linux-x-mips-elf
|
cd linux-x-mips-elf
|
SRCDIR/configure --target mips-elf --prefix=INSTALLDIR \
|
SRCDIR/configure --target mips-elf --prefix=INSTALLDIR \
|
--exec-prefix=INSTALLDIR/H-i386-linux
|
--exec-prefix=INSTALLDIR/H-i386-linux
|
make
|
make
|
make install
|
make install
|
cd ..
|
cd ..
|
mkdir cygwin32-x-mips-elf
|
mkdir cygwin32-x-mips-elf
|
cd cygwin32-x-mips-elf
|
cd cygwin32-x-mips-elf
|
SRCDIR/configure --build=i386-linux-gnu --host=i386-cygwin32 \
|
SRCDIR/configure --build=i386-linux-gnu --host=i386-cygwin32 \
|
--target=mips-elf --prefix=WININSTALLDIR \
|
--target=mips-elf --prefix=WININSTALLDIR \
|
--exec-prefix=WININSTALLDIR/H-i386-cygwin32
|
--exec-prefix=WININSTALLDIR/H-i386-cygwin32
|
make
|
make
|
make install
|
make install
|
|
|
You would then copy the contents of WININSTALLDIR over to the
|
You would then copy the contents of WININSTALLDIR over to the
|
Windows machine, and run the resulting programs.
|
Windows machine, and run the resulting programs.
|
|
|
|
|
File: configure.info, Node: Supporting Canadian Cross, Prev: CCross in Cygnus Tree, Up: Canadian Cross
|
File: configure.info, Node: Supporting Canadian Cross, Prev: CCross in Cygnus Tree, Up: Canadian Cross
|
|
|
Supporting Canadian Cross
|
Supporting Canadian Cross
|
=========================
|
=========================
|
|
|
If you want to make it possible to build a program you are developing
|
If you want to make it possible to build a program you are developing
|
using a Canadian Cross, you must take some care when writing your
|
using a Canadian Cross, you must take some care when writing your
|
configure and make rules. Simple cases will normally work correctly.
|
configure and make rules. Simple cases will normally work correctly.
|
However, it is not hard to write configure and make tests which will
|
However, it is not hard to write configure and make tests which will
|
fail in a Canadian Cross.
|
fail in a Canadian Cross.
|
|
|
* Menu:
|
* Menu:
|
|
|
* CCross in Configure:: Supporting Canadian Cross in Configure Scripts.
|
* CCross in Configure:: Supporting Canadian Cross in Configure Scripts.
|
* CCross in Make:: Supporting Canadian Cross in Makefiles.
|
* CCross in Make:: Supporting Canadian Cross in Makefiles.
|
|
|
|
|
File: configure.info, Node: CCross in Configure, Next: CCross in Make, Up: Supporting Canadian Cross
|
File: configure.info, Node: CCross in Configure, Next: CCross in Make, Up: Supporting Canadian Cross
|
|
|
Supporting Canadian Cross in Configure Scripts
|
Supporting Canadian Cross in Configure Scripts
|
----------------------------------------------
|
----------------------------------------------
|
|
|
In a `configure.in' file, after calling `AC_PROG_CC', you can find
|
In a `configure.in' file, after calling `AC_PROG_CC', you can find
|
out whether this is a Canadian Cross configure by examining the shell
|
out whether this is a Canadian Cross configure by examining the shell
|
variable `cross_compiling'. In a Canadian Cross, which means that the
|
variable `cross_compiling'. In a Canadian Cross, which means that the
|
compiler is a cross compiler, `cross_compiling' will be `yes'. In a
|
compiler is a cross compiler, `cross_compiling' will be `yes'. In a
|
normal configuration, `cross_compiling' will be `no'.
|
normal configuration, `cross_compiling' will be `no'.
|
|
|
You ordinarily do not need to know the type of the build system in a
|
You ordinarily do not need to know the type of the build system in a
|
configure script. However, if you do need that information, you can get
|
configure script. However, if you do need that information, you can get
|
it by using the macro `AC_CANONICAL_SYSTEM', the same macro that is
|
it by using the macro `AC_CANONICAL_SYSTEM', the same macro that is
|
used to determine the target system. This macro will set the variables
|
used to determine the target system. This macro will set the variables
|
`build', `build_alias', `build_cpu', `build_vendor', and `build_os',
|
`build', `build_alias', `build_cpu', `build_vendor', and `build_os',
|
which correspond to the similar `target' and `host' variables, except
|
which correspond to the similar `target' and `host' variables, except
|
that they describe the build system.
|
that they describe the build system.
|
|
|
When writing tests in `configure.in', you must remember that you
|
When writing tests in `configure.in', you must remember that you
|
want to test the host environment, not the build environment.
|
want to test the host environment, not the build environment.
|
|
|
Macros like `AC_CHECK_FUNCS' which use the compiler will test the
|
Macros like `AC_CHECK_FUNCS' which use the compiler will test the
|
host environment. That is because the tests will be done by running the
|
host environment. That is because the tests will be done by running the
|
compiler, which is actually a build cross host compiler. If the
|
compiler, which is actually a build cross host compiler. If the
|
compiler can find the function, that means that the function is present
|
compiler can find the function, that means that the function is present
|
in the host environment.
|
in the host environment.
|
|
|
Tests like `test -f /dev/ptyp0', on the other hand, will test the
|
Tests like `test -f /dev/ptyp0', on the other hand, will test the
|
build environment. Remember that the configure script is running on the
|
build environment. Remember that the configure script is running on the
|
build system, not the host system. If your configure scripts examines
|
build system, not the host system. If your configure scripts examines
|
files, those files will be on the build system. Whatever you determine
|
files, those files will be on the build system. Whatever you determine
|
based on those files may or may not be the case on the host system.
|
based on those files may or may not be the case on the host system.
|
|
|
Most autoconf macros will work correctly for a Canadian Cross. The
|
Most autoconf macros will work correctly for a Canadian Cross. The
|
main exception is `AC_TRY_RUN'. This macro tries to compile and run a
|
main exception is `AC_TRY_RUN'. This macro tries to compile and run a
|
test program. This will fail in a Canadian Cross, because the program
|
test program. This will fail in a Canadian Cross, because the program
|
will be compiled for the host system, which means that it will not run
|
will be compiled for the host system, which means that it will not run
|
on the build system.
|
on the build system.
|
|
|
The `AC_TRY_RUN' macro provides an optional argument to tell the
|
The `AC_TRY_RUN' macro provides an optional argument to tell the
|
configure script what to do in a Canadian Cross. If that argument is
|
configure script what to do in a Canadian Cross. If that argument is
|
not present, you will get a warning when you run `autoconf':
|
not present, you will get a warning when you run `autoconf':
|
warning: AC_TRY_RUN called without default to allow cross compiling
|
warning: AC_TRY_RUN called without default to allow cross compiling
|
|
|
This tells you that the resulting `configure' script will not work with
|
This tells you that the resulting `configure' script will not work with
|
a Canadian Cross.
|
a Canadian Cross.
|
|
|
In some cases while it may better to perform a test at configure
|
In some cases while it may better to perform a test at configure
|
time, it is also possible to perform the test at run time. In such a
|
time, it is also possible to perform the test at run time. In such a
|
case you can use the cross compiling argument to `AC_TRY_RUN' to tell
|
case you can use the cross compiling argument to `AC_TRY_RUN' to tell
|
your program that the test could not be performed at configure time.
|
your program that the test could not be performed at configure time.
|
|
|
There are a few other autoconf macros which will not work correctly
|
There are a few other autoconf macros which will not work correctly
|
with a Canadian Cross: a partial list is `AC_FUNC_GETPGRP',
|
with a Canadian Cross: a partial list is `AC_FUNC_GETPGRP',
|
`AC_FUNC_SETPGRP', `AC_FUNC_SETVBUF_REVERSED', and
|
`AC_FUNC_SETPGRP', `AC_FUNC_SETVBUF_REVERSED', and
|
`AC_SYS_RESTARTABLE_SYSCALLS'. The `AC_CHECK_SIZEOF' macro is
|
`AC_SYS_RESTARTABLE_SYSCALLS'. The `AC_CHECK_SIZEOF' macro is
|
generally not very useful with a Canadian Cross; it permits an optional
|
generally not very useful with a Canadian Cross; it permits an optional
|
argument indicating the default size, but there is no way to know what
|
argument indicating the default size, but there is no way to know what
|
the correct default should be.
|
the correct default should be.
|
|
|
|
|
File: configure.info, Node: CCross in Make, Prev: CCross in Configure, Up: Supporting Canadian Cross
|
File: configure.info, Node: CCross in Make, Prev: CCross in Configure, Up: Supporting Canadian Cross
|
|
|
Supporting Canadian Cross in Makefiles.
|
Supporting Canadian Cross in Makefiles.
|
---------------------------------------
|
---------------------------------------
|
|
|
The main Canadian Cross issue in a `Makefile' arises when you want
|
The main Canadian Cross issue in a `Makefile' arises when you want
|
to use a subsidiary program to generate code or data which you will then
|
to use a subsidiary program to generate code or data which you will then
|
include in your real program.
|
include in your real program.
|
|
|
If you compile this subsidiary program using `$(CC)' in the usual
|
If you compile this subsidiary program using `$(CC)' in the usual
|
way, you will not be able to run it. This is because `$(CC)' will
|
way, you will not be able to run it. This is because `$(CC)' will
|
build a program for the host system, but the program is being built on
|
build a program for the host system, but the program is being built on
|
the build system.
|
the build system.
|
|
|
You must instead use a compiler for the build system, rather than the
|
You must instead use a compiler for the build system, rather than the
|
host system. In the Cygnus tree, this make variable `$(CC_FOR_BUILD)'
|
host system. In the Cygnus tree, this make variable `$(CC_FOR_BUILD)'
|
will hold a compiler for the build system.
|
will hold a compiler for the build system.
|
|
|
Note that you should not include `config.h' in a file you are
|
Note that you should not include `config.h' in a file you are
|
compiling with `$(CC_FOR_BUILD)'. The `configure' script will build
|
compiling with `$(CC_FOR_BUILD)'. The `configure' script will build
|
`config.h' with information for the host system. However, you are
|
`config.h' with information for the host system. However, you are
|
compiling the file using a compiler for the build system (a native
|
compiling the file using a compiler for the build system (a native
|
compiler). Subsidiary programs are normally simple filters which do no
|
compiler). Subsidiary programs are normally simple filters which do no
|
user interaction, and it is normally possible to write them in a highly
|
user interaction, and it is normally possible to write them in a highly
|
portable fashion so that the absence of `config.h' is not crucial.
|
portable fashion so that the absence of `config.h' is not crucial.
|
|
|
The gcc `Makefile.in' shows a complex situation in which certain
|
The gcc `Makefile.in' shows a complex situation in which certain
|
files, such as `rtl.c', must be compiled into both subsidiary programs
|
files, such as `rtl.c', must be compiled into both subsidiary programs
|
run on the build system and into the final program. This approach may
|
run on the build system and into the final program. This approach may
|
be of interest for advanced build system hackers. Note that the build
|
be of interest for advanced build system hackers. Note that the build
|
system compiler is rather confusingly called `HOST_CC'.
|
system compiler is rather confusingly called `HOST_CC'.
|
|
|
|
|
File: configure.info, Node: Cygnus Configure, Next: Multilibs, Prev: Canadian Cross, Up: Top
|
File: configure.info, Node: Cygnus Configure, Next: Multilibs, Prev: Canadian Cross, Up: Top
|
|
|
Cygnus Configure
|
Cygnus Configure
|
****************
|
****************
|
|
|
The Cygnus configure script predates autoconf. All of its
|
The Cygnus configure script predates autoconf. All of its
|
interesting features have been incorporated into autoconf. No new
|
interesting features have been incorporated into autoconf. No new
|
programs should be written to use the Cygnus configure script.
|
programs should be written to use the Cygnus configure script.
|
|
|
However, the Cygnus configure script is still used in a few places:
|
However, the Cygnus configure script is still used in a few places:
|
at the top of the Cygnus tree and in a few target libraries in the
|
at the top of the Cygnus tree and in a few target libraries in the
|
Cygnus tree. Until those uses have been replaced with autoconf, some
|
Cygnus tree. Until those uses have been replaced with autoconf, some
|
brief notes are appropriate here. This is not complete documentation,
|
brief notes are appropriate here. This is not complete documentation,
|
but it should be possible to use this as a guide while examining the
|
but it should be possible to use this as a guide while examining the
|
scripts themselves.
|
scripts themselves.
|
|
|
* Menu:
|
* Menu:
|
|
|
* Cygnus Configure Basics:: Cygnus Configure Basics.
|
* Cygnus Configure Basics:: Cygnus Configure Basics.
|
* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries.
|
* Cygnus Configure in C++ Libraries:: Cygnus Configure in C++ Libraries.
|
|
|
|
|
File: configure.info, Node: Cygnus Configure Basics, Next: Cygnus Configure in C++ Libraries, Up: Cygnus Configure
|
File: configure.info, Node: Cygnus Configure Basics, Next: Cygnus Configure in C++ Libraries, Up: Cygnus Configure
|
|
|
Cygnus Configure Basics
|
Cygnus Configure Basics
|
=======================
|
=======================
|
|
|
Cygnus configure does not use any generated files; there is no
|
Cygnus configure does not use any generated files; there is no
|
program corresponding to `autoconf'. Instead, there is a single shell
|
program corresponding to `autoconf'. Instead, there is a single shell
|
script named `configure' which may be found at the top of the Cygnus
|
script named `configure' which may be found at the top of the Cygnus
|
tree. This shell script was written by hand; it was not generated by
|
tree. This shell script was written by hand; it was not generated by
|
autoconf, and it is incorrect, and indeed harmful, to run `autoconf' in
|
autoconf, and it is incorrect, and indeed harmful, to run `autoconf' in
|
the top level of a Cygnus tree.
|
the top level of a Cygnus tree.
|
|
|
Cygnus configure works in a particular directory by examining the
|
Cygnus configure works in a particular directory by examining the
|
file `configure.in' in that directory. That file is broken into four
|
file `configure.in' in that directory. That file is broken into four
|
separate shell scripts.
|
separate shell scripts.
|
|
|
The first is the contents of `configure.in' up to a line that starts
|
The first is the contents of `configure.in' up to a line that starts
|
with `# per-host:'. This is the common part.
|
with `# per-host:'. This is the common part.
|
|
|
The second is the rest of `configure.in' up to a line that starts
|
The second is the rest of `configure.in' up to a line that starts
|
with `# per-target:'. This is the per host part.
|
with `# per-target:'. This is the per host part.
|
|
|
The third is the rest of `configure.in' up to a line that starts
|
The third is the rest of `configure.in' up to a line that starts
|
with `# post-target:'. This is the per target part.
|
with `# post-target:'. This is the per target part.
|
|
|
The fourth is the remainder of `configure.in'. This is the post
|
The fourth is the remainder of `configure.in'. This is the post
|
target part.
|
target part.
|
|
|
If any of these comment lines are missing, the corresponding shell
|
If any of these comment lines are missing, the corresponding shell
|
script is empty.
|
script is empty.
|
|
|
Cygnus configure will first execute the common part. This must set
|
Cygnus configure will first execute the common part. This must set
|
the shell variable `srctrigger' to the name of a source file, to
|
the shell variable `srctrigger' to the name of a source file, to
|
confirm that Cygnus configure is looking at the right directory. This
|
confirm that Cygnus configure is looking at the right directory. This
|
may set the shell variables `package_makefile_frag' and
|
may set the shell variables `package_makefile_frag' and
|
`package_makefile_rules_frag'.
|
`package_makefile_rules_frag'.
|
|
|
Cygnus configure will next set the `build' and `host' shell
|
Cygnus configure will next set the `build' and `host' shell
|
variables, and execute the per host part. This may set the shell
|
variables, and execute the per host part. This may set the shell
|
variable `host_makefile_frag'.
|
variable `host_makefile_frag'.
|
|
|
Cygnus configure will next set the `target' variable, and execute
|
Cygnus configure will next set the `target' variable, and execute
|
the per target part. This may set the shell variable
|
the per target part. This may set the shell variable
|
`target_makefile_frag'.
|
`target_makefile_frag'.
|
|
|
Any of these scripts may set the `subdirs' shell variable. This
|
Any of these scripts may set the `subdirs' shell variable. This
|
variable is a list of subdirectories where a `Makefile.in' file may be
|
variable is a list of subdirectories where a `Makefile.in' file may be
|
found. Cygnus configure will automatically look for a `Makefile.in'
|
found. Cygnus configure will automatically look for a `Makefile.in'
|
file in the current directory. The `subdirs' shell variable is not
|
file in the current directory. The `subdirs' shell variable is not
|
normally used, and I believe that the only directory which uses it at
|
normally used, and I believe that the only directory which uses it at
|
present is `newlib'.
|
present is `newlib'.
|
|
|
For each `Makefile.in', Cygnus configure will automatically create a
|
For each `Makefile.in', Cygnus configure will automatically create a
|
`Makefile' by adding definitions for `make' variables such as `host'
|
`Makefile' by adding definitions for `make' variables such as `host'
|
and `target', and automatically editing the values of `make' variables
|
and `target', and automatically editing the values of `make' variables
|
such as `prefix' if they are present.
|
such as `prefix' if they are present.
|
|
|
Also, if any of the `makefile_frag' shell variables are set, Cygnus
|
Also, if any of the `makefile_frag' shell variables are set, Cygnus
|
configure will interpret them as file names relative to either the
|
configure will interpret them as file names relative to either the
|
working directory or the source directory, and will read the contents of
|
working directory or the source directory, and will read the contents of
|
the file into the generated `Makefile'. The file contents will be read
|
the file into the generated `Makefile'. The file contents will be read
|
in after the first line in `Makefile.in' which starts with `####'.
|
in after the first line in `Makefile.in' which starts with `####'.
|
|
|
These `Makefile' fragments are used to customize behaviour for a
|
These `Makefile' fragments are used to customize behaviour for a
|
particular host or target. They serve to select particular files to
|
particular host or target. They serve to select particular files to
|
compile, and to define particular preprocessor macros by providing
|
compile, and to define particular preprocessor macros by providing
|
values for `make' variables which are then used during compilation.
|
values for `make' variables which are then used during compilation.
|
Cygnus configure, unlike autoconf, normally does not do feature tests,
|
Cygnus configure, unlike autoconf, normally does not do feature tests,
|
and normally requires support to be added manually for each new host.
|
and normally requires support to be added manually for each new host.
|
|
|
The `Makefile' fragment support is similar to the autoconf
|
The `Makefile' fragment support is similar to the autoconf
|
`AC_SUBST_FILE' macro.
|
`AC_SUBST_FILE' macro.
|
|
|
After creating each `Makefile', the post target script will be run
|
After creating each `Makefile', the post target script will be run
|
(i.e., it may be run several times). This script may further customize
|
(i.e., it may be run several times). This script may further customize
|
the `Makefile'. When it is run, the shell variable `Makefile' will
|
the `Makefile'. When it is run, the shell variable `Makefile' will
|
hold the name of the `Makefile', including the appropriate directory
|
hold the name of the `Makefile', including the appropriate directory
|
component.
|
component.
|
|
|
Like an autoconf generated `configure' script, Cygnus configure will
|
Like an autoconf generated `configure' script, Cygnus configure will
|
create a file named `config.status' which, when run, will automatically
|
create a file named `config.status' which, when run, will automatically
|
recreate the configuration. The `config.status' file will simply
|
recreate the configuration. The `config.status' file will simply
|
execute the Cygnus configure script again with the appropriate
|
execute the Cygnus configure script again with the appropriate
|
arguments.
|
arguments.
|
|
|
Any of the parts of `configure.in' may set the shell variables
|
Any of the parts of `configure.in' may set the shell variables
|
`files' and `links'. Cygnus configure will set up symlinks from the
|
`files' and `links'. Cygnus configure will set up symlinks from the
|
names in `links' to the files named in `files'. This is similar to the
|
names in `links' to the files named in `files'. This is similar to the
|
autoconf `AC_LINK_FILES' macro.
|
autoconf `AC_LINK_FILES' macro.
|
|
|
Finally, any of the parts of `configure.in' may set the shell
|
Finally, any of the parts of `configure.in' may set the shell
|
variable `configdirs' to a set of subdirectories. If it is set, Cygnus
|
variable `configdirs' to a set of subdirectories. If it is set, Cygnus
|
configure will recursively run the configure process in each
|
configure will recursively run the configure process in each
|
subdirectory. If the subdirectory uses Cygnus configure, it will
|
subdirectory. If the subdirectory uses Cygnus configure, it will
|
contain a `configure.in' file but no `configure' file, in which case
|
contain a `configure.in' file but no `configure' file, in which case
|
Cygnus configure will invoke itself recursively. If the subdirectory
|
Cygnus configure will invoke itself recursively. If the subdirectory
|
has a `configure' file, Cygnus configure assumes that it is an autoconf
|
has a `configure' file, Cygnus configure assumes that it is an autoconf
|
generated `configure' script, and simply invokes it directly.
|
generated `configure' script, and simply invokes it directly.
|
|
|
|
|
File: configure.info, Node: Cygnus Configure in C++ Libraries, Prev: Cygnus Configure Basics, Up: Cygnus Configure
|
File: configure.info, Node: Cygnus Configure in C++ Libraries, Prev: Cygnus Configure Basics, Up: Cygnus Configure
|
|
|
Cygnus Configure in C++ Libraries
|
Cygnus Configure in C++ Libraries
|
=================================
|
=================================
|
|
|
The C++ library configure system, written by Per Bothner, deserves
|
The C++ library configure system, written by Per Bothner, deserves
|
special mention. It uses Cygnus configure, but it does feature testing
|
special mention. It uses Cygnus configure, but it does feature testing
|
like that done by autoconf generated `configure' scripts. This
|
like that done by autoconf generated `configure' scripts. This
|
approach is used in the libraries `libio', `libstdc++', and `libg++'.
|
approach is used in the libraries `libio', `libstdc++', and `libg++'.
|
|
|
Most of the `Makefile' information is written out by the shell
|
Most of the `Makefile' information is written out by the shell
|
script `libio/config.shared'. Each `configure.in' file sets certain
|
script `libio/config.shared'. Each `configure.in' file sets certain
|
shell variables, and then invokes `config.shared' to create two package
|
shell variables, and then invokes `config.shared' to create two package
|
`Makefile' fragments. These fragments are then incorporated into the
|
`Makefile' fragments. These fragments are then incorporated into the
|
resulting `Makefile' by the Cygnus configure script.
|
resulting `Makefile' by the Cygnus configure script.
|
|
|
The file `_G_config.h' is created in the `libio' object directory by
|
The file `_G_config.h' is created in the `libio' object directory by
|
running the shell script `libio/gen-params'. This shell script uses
|
running the shell script `libio/gen-params'. This shell script uses
|
feature tests to define macros and typedefs in `_G_config.h'.
|
feature tests to define macros and typedefs in `_G_config.h'.
|
|
|
|
|
File: configure.info, Node: Multilibs, Next: FAQ, Prev: Cygnus Configure, Up: Top
|
File: configure.info, Node: Multilibs, Next: FAQ, Prev: Cygnus Configure, Up: Top
|
|
|
Multilibs
|
Multilibs
|
*********
|
*********
|
|
|
For some targets gcc may have different processor requirements
|
For some targets gcc may have different processor requirements
|
depending upon command line options. An obvious example is the
|
depending upon command line options. An obvious example is the
|
`-msoft-float' option supported on several processors. This option
|
`-msoft-float' option supported on several processors. This option
|
means that the floating point registers are not available, which means
|
means that the floating point registers are not available, which means
|
that floating point operations must be done by calling an emulation
|
that floating point operations must be done by calling an emulation
|
subroutine rather than by using machine instructions.
|
subroutine rather than by using machine instructions.
|
|
|
For such options, gcc is often configured to compile target libraries
|
For such options, gcc is often configured to compile target libraries
|
twice: once with `-msoft-float' and once without. When gcc compiles
|
twice: once with `-msoft-float' and once without. When gcc compiles
|
target libraries more than once, the resulting libraries are called
|
target libraries more than once, the resulting libraries are called
|
"multilibs".
|
"multilibs".
|
|
|
Multilibs are not really part of the GNU configure and build system,
|
Multilibs are not really part of the GNU configure and build system,
|
but we discuss them here since they require support in the `configure'
|
but we discuss them here since they require support in the `configure'
|
scripts and `Makefile's used for target libraries.
|
scripts and `Makefile's used for target libraries.
|
|
|
* Menu:
|
* Menu:
|
|
|
* Multilibs in gcc:: Multilibs in gcc.
|
* Multilibs in gcc:: Multilibs in gcc.
|
* Multilibs in Target Libraries:: Multilibs in Target Libraries.
|
* Multilibs in Target Libraries:: Multilibs in Target Libraries.
|
|
|
|
|
File: configure.info, Node: Multilibs in gcc, Next: Multilibs in Target Libraries, Up: Multilibs
|
File: configure.info, Node: Multilibs in gcc, Next: Multilibs in Target Libraries, Up: Multilibs
|
|
|
Multilibs in gcc
|
Multilibs in gcc
|
================
|
================
|
|
|
In gcc, multilibs are defined by setting the variable
|
In gcc, multilibs are defined by setting the variable
|
`MULTILIB_OPTIONS' in the target `Makefile' fragment. Several other
|
`MULTILIB_OPTIONS' in the target `Makefile' fragment. Several other
|
`MULTILIB' variables may also be defined there. *Note The Target
|
`MULTILIB' variables may also be defined there. *Note The Target
|
Makefile Fragment: (gcc)Target Fragment.
|
Makefile Fragment: (gcc)Target Fragment.
|
|
|
If you have built gcc, you can see what multilibs it uses by running
|
If you have built gcc, you can see what multilibs it uses by running
|
it with the `-print-multi-lib' option. The output `.;' means that no
|
it with the `-print-multi-lib' option. The output `.;' means that no
|
multilibs are used. In general, the output is a sequence of lines, one
|
multilibs are used. In general, the output is a sequence of lines, one
|
per multilib. The first part of each line, up to the `;', is the name
|
per multilib. The first part of each line, up to the `;', is the name
|
of the multilib directory. The second part is a list of compiler
|
of the multilib directory. The second part is a list of compiler
|
options separated by `@' characters.
|
options separated by `@' characters.
|
|
|
Multilibs are built in a tree of directories. The top of the tree,
|
Multilibs are built in a tree of directories. The top of the tree,
|
represented by `.' in the list of multilib directories, is the default
|
represented by `.' in the list of multilib directories, is the default
|
library to use when no special compiler options are used. The
|
library to use when no special compiler options are used. The
|
subdirectories of the tree hold versions of the library to use when
|
subdirectories of the tree hold versions of the library to use when
|
particular compiler options are used.
|
particular compiler options are used.
|
|
|
|
|
