MatCat.OpenSource/8sa1-binutils-gdb
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

recording file death

Browse Source
This commit is contained in:
K. Richard Pixley 1992-12-08 05:27:22 +00:00
parent 017349fbcf
commit e7a8768db6
9 changed files with 0 additions and 7115 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

573
DOC.configure
View File

@ -1,573 +0,0 @@
On Configuring Development Tools
K. Richard Pixley
Cygnus Support
Last Mod Tue Oct 1 21:20:21 PDT 1991, by rich@cygnus.com
INTRO
-----
This document attempts to describe the general concepts behind
configuration of the Cygnus Support release of the GNU Development
Tools. It also discusses common usage. Eventually, FIXME, there
will also be a man page for "configure", an "info" tree, etc.
BASICS
------
Some Basic Terms:
There are a lot of terms that are frequently used when discussing
development tools. Most of the common terms have been used for
several different concepts such that their meanings have become
ambiguous to the point of being confusing. Typically, we only
guess at their meanings from context and we frequently guess
wrong.
This document uses very few terms by comparison. The intent is to
make the concepts as clear as possible in order to convey the
usage and intent of these tools.
"Programs" run on "machines". Programs are very nearly always
written in "source". Programs are "built" from source.
"Compilation" is a process that is frequently, but not always,
used when building programs.
Host Environments:
In this document, the word "host" refers to the environment in
which this source will be compiled. "host" and "host name" have
nothing to do with the proper name of your host, like "ucbvax",
"prep.ai.mit.edu" or "att.com". Instead they refer to things like
"sun4" and "dec3100".
Forget for a moment that this particular directory of source is
the source for a development environment. Instead, pretend that
it is the source for a simpler, more mundane, application, say, a
desk calculator.
Source that can be compiled in more than one environment,
generally needs to be set up for each environment explicitly.
Here we refer to that process as configuration. That is, we
configure the source for a host.
For example, if we wanted to configure our mythical desk
calculator to compile on a SparcStation, we might configure for
host sun4. With our configuration system:
cd desk-calculator ; ./configure sun4
does the trick. "configure" is a shell script that sets up
Makefiles, subdirectories, and symbolic links appropriate for
compiling the source on a sun4.
The "host" environment does not necessarily refer to the machine
on which the tools are built. It is possible to provide a sun3
development environment on a sun4. If we wanted to use a cross
compiler on the sun4 to build a program intended to be run on a
sun3, we would configure the source for sun3.
cd desk-calculator ; ./configure sun3
The fact that we are actually building the program on a sun4 makes
no difference if the sun3 cross compiler presents an environment
that looks like a sun3 from the point of view of the desk
calculator source code. Specifically, the environment is a sun3
environment if the header files, predefined symbols, and libraries
appear as they do on a sun3.
Nor does the host environment refer to the the machine on which
the program to be built will run. It is possible to provide a
sun3 emulation environment on a sun4 such that programs built in a
sun3 development environment actually run on the sun4.
Host environment simply refers to the environment in which the
program will be built from the source.
Configuration Time Options:
Many programs have compile time options. That is, features of the
program that are either compiled into the program or not based on a
choice made by the person who builds the program. We refer to these
as "configuration options". For example, our desk calculator might be
capable of being compiled into a program that either uses infix
notation or postfix as a configuration option. For a sun3, chosing
infix might be:
./configure sun3 +notation=infix
while a sun4 with postfix might be:
./configure sun4 +notation=postfix
If we wanted to build both at the same time, in the same directory
structure, the intermediate pieces used in the build process must
be kept separate.
./configure sun4 +subdirs +notation=postfix
./configure sun3 +subdirs +notation=infix
will create subdirectories for the intermediate pieces of the sun4
and sun3 configurations. This is necessary as previous systems
were only capable of one configuration at a time. A second
configuration overwrote the first. We've chosen to retain this
behaviour so the "+subdirs" configuration option is necessary
to get the new behaviour. The order of the arguments doesn't
matter. There should be exactly one argument without a leading
'+' sign and that argument will be assumed to be the host name.
From here on the examples will assume that you want to build the
tools "in place" and won't show the "+subdirs" option, but
remember that it is available.
In order to actually install the program, the configuration system
needs to know where you would like the program installed. The
default location is /usr/local. We refer to this location as
$(destdir). All user visible programs will be installed in
$(destdir)/bin. All other programs and files will be installed in
a subdirectory of $(destdir)/lib.
You can elect to change $(destdir) only as a configuration time
option.
./configure sun4 +notation=postfix +destdir=/local
Will configure the source such that:
make install
will put it's programs in /local/bin and /local/lib/gcc. If you
change $(destdir) after building the source, you will need to:
make clean
before the change will be propogated properly. This is because
some tools need to know the locations of other tools.
With these concepts in mind, we can drop the desk calculator and
move on to the application that resides in these directories,
namely, the source to a development environment.
SPECIFICS
---------
The GNU Development Tools can be built on a wide variety of hosts.
So, of course, they must be configured. Like the last example,
./configure sun4 +destdir=/local
./configure sun3 +destdir=/local
will configure the source to be built in subdirectories, in order
to keep the intermediate pieces separate, and to be installed in
/local.
When built with suitable development environments, these will be
native tools. We'll explain the term "native" later.
BUILDING DEVELOPMENT ENVIRONMENTS
---------------------------------
The Cygnus Support GNU development tools can not only be built
with a number of host development environments, they can also be
configured to create a number of different development
environments on each of those hosts. We refer to a specific
development environment created as a "target". That is, the word
"target" refers to the development environment produced by
compiling this source and installing the resulting programs.
For the Cygnus Support GNU development tools, the default target
is the same as the host. That is, the development environment
produced is intended to be compatible with the environment used to
build the tools.
In the example above, we created two configurations, one for sun4
and one for sun3. The first configuration is expecting to be
built in a sun4 development environment, to create a sun4
development environment. It doesn't necessarily need to be built
on a sun4 if a sun4 development environment is available
elsewhere. Likewise, if the available sun4 development
environment produces executables intended for something other than
sun4, then the development environment built from this sun4
configuration will run on something other than a sun4. From the
point of view of the configuration system and the GNU development
tools source, this doesn't matter. What matters is that they will
be built in a sun4 environment.
Similarly, the second configuration given above is expecting to be
built in a sun3 development environment, to create a sun3
development environment.
The development environment produced, is a configuration time
option, just like $(destdir).
./configure sun4 +destdir=/local +target=sun3
./configure sun3 +destdir=/local +target=sun4
In this example, like before, we create two configurations. The
first is intended to be built in a sun4 environment, in
subdirectories, to be installed in /local. The second is intended
to be built in a sun3 environment, in subdirectories, to be
installed in /local.
Unlike the previous example, the first configuration will produce
a sun3 development environment, perhaps even suitable for building
the second configuration. Likewise, the second configuration will
produce a sun4 development environment, perhaps even suitable for
building the first configuration.
The development environment used to build these configurations
will determine the machines on which the resulting development
environments can be used.
A WALK THROUGH
--------------
Native Development Environments:
Let us assume for a moment that you have a sun4 and that with your
sun4 you received a development environment. This development
environment is intended to be run on your sun4 to build programs
that can be run on your sun4. You could, for instance, run this
development environment on your sun4 to build our example desk
calculator program. You could then run the desk calculator
program on your sun4.
The resulting desk calculator program is referred to as a "native"
program. The development environment itself is composed of native
programs that, when run, build other native programs. Any other
program is referred to as "foreign". Programs intended for other
machines are foreign programs.
This type of development environment, which is by far the most
common, is refered to as "native". That is, a native development
environment runs on some machine to build programs for that same
machine. The process of using a native development environment to
build native programs is called a "native" build.
./configure sun4
Will configure this source such that when built in a sun4
development environment, with a development environment that
builds programs intended to be run on sun4 machines, the programs
built will be native programs and the resulting development
environment will be a native development environment.
The development system that came with your sun4 is one such
environment. Using it to build the GNU Development Tools is a
very common activity and the resulting development environment is
very popular.
make all
will build the tools as configured and will assume that you want
to use the native development environment that came with your
machine.
Using a development environment to build a development environment
is called "bootstrapping". The Cygnus Support release of the GNU
Development Tools is capable of bootstrapping itself. This is a
very powerful feature that we'll return to later. For now, let's
pretend that you used the native development environment that came
with your sun4 to bootstrap the Cygnus Support release and let's
call the new development environment stage1.
Why bother? Well, most people find that the Cygnus Support
release builds programs that run faster and take up less space
than the native development environments that came with their
machines. Some people didn't get development environments with
their machines and some people just like using the GNU tools
better than using other tools.
While you're at it, if the GNU tools produce better programs, maybe
you should use them to build the GNU tools. It's a good idea, so
let's pretend that you do. Let's call the new development
environment stage2.
So far you've built a development environment, stage1, and you've
used stage1 to build a new, faster and smaller development
environment, stage2, but you haven't run any of the programs that
the GNU tools have built. You really don't yet know if these
tools work. Do you have any programs built with the GNU tools?
Yes, you do. stage2. What does that program do? It builds
programs. Ok, do you have any source handy to build into a
program? Yes, you do. The GNU tools themselves. In fact, if you
use stage2 to build the GNU tools again the resulting programs
should be identical to stage2. Let's pretend that you do and call
the new development environment stage3.
You've just completed what's called a "three stage boot". You now
have a small, fast, somewhat tested, development environment.
make bootstrap
will do a three stage boot across all tools and will compare
stage2 to stage3 and complain if they are not identical.
Once built,
make install
will install the development environment in the default location
or in $(destdir) if you specified an alternate when you
configured. In fact, you can skip the "make all" part and just
"make install" which will make sure that the development
environment is built before attempting to install anything. Even
better, for configurations where host is the same as target, like
this one, "make install" will make sure that a "make bootstrap" is
done before installing anything.
Any development environment that is not a native development
environment is refered to as a "cross" development environment.
There are many different types of cross development environments
but most fall into one of FIXME basic categories.
Emulation Environments:
The first category of cross development environment is called
"emulation". There are two primary types of emulation, but both
types result in programs that run on the native host.
The first type is "software emulation". This form of cross
development environment involves a native program that when run on
the native host, is capable of interpreting, and in most aspects
running, a program intended for some other machine. This
technique is typically used when the other machine is either too
expensive, too slow, too fast, or not available, perhaps because
it hasn't yet been built. The native, interpreting program is
called a "software emulator".
The GNU Development Tools do not currently include any software
emulators. Some do exist and the GNU Development Tools can be
configured to create simple cross development environments for
with these emulators. More on this later.
The second type of emulation is when source intended for some
other development environment is built into a program intended for
the native host. The concept of universes in operating systems
and hosted operating systems are two such development
environments.
The Cygnus Support Release of the GNU Development Tools can be
configured for one such emulation at this time.
./configure sun4 +ansi
will configure the source such that when built in a sun4
development environment the resulting development environment is
capable of building sun4 programs from strictly conforming ANSI
X3J11 C source. Remember that the environment used to build the
tools determines the machine on which this tools will run, so the
resulting programs aren't necessarily intended to run on a sun4,
although they usually are. Also note that the source for the GNU
tools is not strictly conforming ANSI source so this configuration
cannot be used to bootstrap the GNU tools.
Simple Cross Environments:
./configure sun4 +target=a29k
will configure the tools such that when compiled in a sun4
development environment the resulting development environment can
be used to create programs intended for an a29k. Again, this does
not necessarily mean that the new development environment can be
run on a sun4. That would depend on the development environment
used to build these tools.
Earlier you saw how to configure the tools to build a native
development environment, that is, a development environment that
runs on your sun4 and builds programs for your sun4. Let's
pretend that you use stage3 to build this simple cross
configuration and let's call the new development environment
gcc-a29k. Remember that this is a native build. Gcc-a29k is a
collection of native programs intended to run on your sun4.
That's what stage3 builds, programs for your sun4. Gcc-a29k
represents an a29k development environment that builds programs
intended to run on an a29k. But, remember, gcc-a29k runs on your
sun4. Programs built with gcc-a29k will run on your sun4 only
with the help of an appropriate software emulator.
Building gcc-a29k is also a bootstrap but of a slightly different
sort. We call gcc-a29k a simple cross environment and using
gcc-a29k to build a program intended for a29k is called "crossing
to" a29k. Simple cross environments are the second category of
cross development environments.
Crossing Into Targets:
./configure a29k +target=a29k
will configure the tools such that when compiled in an a29k
development environment, the resulting development environment can
be used to create programs intended for an a29k. Again, this does
not necessarily mean that the new development environment can be
run on an a29k. That would depend on the development environment
used to build these tools.
If you've been following along this walk through, then you've
already built an a29k environment, namely gcc-a29k. Let's pretend
you use gcc-a29k to build the current configuration.
Gcc-a29k builds programs intended for the a29k so the new
development environment will be intended for use on an a29k. That
is, this new gcc consists of programs that are foreign to your
sun4. They cannot be run on your sun4.
The process of building this configuration is another a bootstrap.
This bootstrap is also a cross to a29k. Because this type of
build is both a bootstrap and a cross to a29k, it is sometimes
referred to as a "cross into" a29k. This new development
environment isn't really a cross development environment at all.
It is intended to run on an a29k to produce programs for an a29k.
You'll remember that this makes it, by definition, an a29k native
compiler. "Crossing into" has been introduced here not because it
is a type of cross development environment, but because it is
frequently confused one. The process is "a cross" but the
resulting development environment is a native development
environment.
You could not have built this configuration with stage3, because
stage3 doesn't provide an a29k environment. Instead it provides a
sun4 environment.
If you happen to have an a29k lying around, you could now use
this fresh development environment on the a29k to three-stage
these tools all over again. This process would look just like it
did when we built the native sun4 development environment because
we would be building another native development environment, this
one on a29k.
The Three Party Cross:
So far you've seen that our development environment source must be
configured for a specific host and for a specific target. You've
also seen that the resulting development environment depends on
the development environment used in the build process.
When all four match identically, that is, the configured host, the
configured target, the environment presented by the development
environment used in the build, and the machine on which the
resulting development environment is intended to run, then the new
development environment will be a native development environment.
When all four match except the configured host, then we can assume
that the development environment used in the build is some form of
library emulation.
When all four match except for the configured target, then the
resulting development environment will be a simple cross
development environment.
When all four match except for the host on which the development
environment used in the build runs, the build process is a "cross
into" and the resulting development environment will be native to
some other machine.
Most of the other permutations do exist in some form, but only one
more is interesting to the current discussion.
./configure a29k +target=sun3
will configure the tools such that when compiled in an a29k
development environment, the resulting development environment can
be used to create programs intended for a sun3. Again, this does
not necessarily mean that the new development environment can be
run on an a29k. That would depend on the development environment
used to build these tools.
If you are still following along, then you have two a29k
development environments, the native development environment that
runs on a29k, and the simple cross that runs on your sun4. If you
use the a29k native development environment on the a29k, you will
be doing the same thing we did a while back, namely building a
simple cross from a29k to sun3. Let's pretend that instead, you
use gcc-a29k, the simple cross development environment that runs
on sun4 but produces programs for a29k.
The resulting development environment will run on a29k because
that's what gcc-a29k builds, a29k programs. This development
environment will produce programs for a sun3 because that is how
it was configured. This means that the resulting development
environment is a simple cross.
There really isn't a common name for this process because very few
development environments are capable of being configured this
extensively. For the sake of discussion, let's call this process
a "three party cross".
FINAL NOTES
-----------
By "configures", I mean that links, Makefile, .gdbinit, and
config.status are built. Configuration is always done from the source
directory.
* "./configure name" configures this directory, perhaps recursively,
for a single host+target pair where the host and target are both
"name". If a previous configuration existed, it will be
overwritten.
* "./configure hostname +target=targetname" configures this directory,
perhaps recursively, for a single host+target pair where the host is
hostname and target is targetname. If a previous configuration
existed, it will be overwritten.
* "./configure +subdirs hostname +target=targetname" creates a
subdirectories H-hostname and H-hostname/T-targetname and
configures H-hostname/T-targetname. For now, makes should
be done from H-hostname/T-targetname. "./configure +sub name"
works as expected. That is, it creates H-name and
H-name/T-name and configures the latter.
Hacking configurations:
The configure scripts essentially do three things, create
subdirectories if appropriate, build a Makefile, and create links to
files, all based on and tailored to, a specific host+target pair. The
scripts also create a .gdbinit if appropriate but this is not
tailored.
The Makefile is created by prepending some variable definitions to a
Makefile template called Makefile.in and then inserting host and
target specific Makefile fragments. The variables are set based on
the chosen host+target pair and build style, that is, if you use
subdirectories or not. The host and target specific Makefile may or
may not exist. If fragments
* Makefiles can be edited directly, but those changes will eventually
be lost. Changes intended to be permanent for a specific host
should be made to the host specific Makefile fragment. This should
be in ./config/hmake-host if it exists. Changes intended to be
permanent for a specific target should be made to the target
specific Makefile fragment. This should be in ./config/tmake-target
if it exists. Changes intended to be permanent for the directory
should be made in Makefile.in. To propogate changes to any of
these, either use "make Makefile" or re-configure from the source
directory.
* configure can be edited directly, but those changes will eventually
be lost. Changes intended to be permanent for a specific directory
should be made to configure.in. Changes intended to be permanent
for all configure scripts should be made to configure.template.
Propogating changes to configure.in requires the presence of
configure.template which normally resides in the uppermost directory
you received. To propogate changes to either configure.template or
a configure.in, use "configure +template=pathtothetemplate".
This will configure the configure scripts themselves, recursively if
appropriate.
* "./configure -srcdir=foo" is not supported yet. At the moment, things
will probably be configured correctly only for leaf directories, and
even they will not have paths to libraries set properly.

573
README.configure
View File

@ -1,573 +0,0 @@
On Configuring Development Tools
K. Richard Pixley
Cygnus Support
Last Mod Tue Oct 1 21:20:21 PDT 1991, by rich@cygnus.com
INTRO
-----
This document attempts to describe the general concepts behind
configuration of the Cygnus Support release of the GNU Development
Tools. It also discusses common usage. Eventually, FIXME, there
will also be a man page for "configure", an "info" tree, etc.
BASICS
------
Some Basic Terms:
There are a lot of terms that are frequently used when discussing
development tools. Most of the common terms have been used for
several different concepts such that their meanings have become
ambiguous to the point of being confusing. Typically, we only
guess at their meanings from context and we frequently guess
wrong.
This document uses very few terms by comparison. The intent is to
make the concepts as clear as possible in order to convey the
usage and intent of these tools.
"Programs" run on "machines". Programs are very nearly always
written in "source". Programs are "built" from source.
"Compilation" is a process that is frequently, but not always,
used when building programs.
Host Environments:
In this document, the word "host" refers to the environment in
which this source will be compiled. "host" and "host name" have
nothing to do with the proper name of your host, like "ucbvax",
"prep.ai.mit.edu" or "att.com". Instead they refer to things like
"sun4" and "dec3100".
Forget for a moment that this particular directory of source is
the source for a development environment. Instead, pretend that
it is the source for a simpler, more mundane, application, say, a
desk calculator.
Source that can be compiled in more than one environment,
generally needs to be set up for each environment explicitly.
Here we refer to that process as configuration. That is, we
configure the source for a host.
For example, if we wanted to configure our mythical desk
calculator to compile on a SparcStation, we might configure for
host sun4. With our configuration system:
cd desk-calculator ; ./configure sun4
does the trick. "configure" is a shell script that sets up
Makefiles, subdirectories, and symbolic links appropriate for
compiling the source on a sun4.
The "host" environment does not necessarily refer to the machine
on which the tools are built. It is possible to provide a sun3
development environment on a sun4. If we wanted to use a cross
compiler on the sun4 to build a program intended to be run on a
sun3, we would configure the source for sun3.
cd desk-calculator ; ./configure sun3
The fact that we are actually building the program on a sun4 makes
no difference if the sun3 cross compiler presents an environment
that looks like a sun3 from the point of view of the desk
calculator source code. Specifically, the environment is a sun3
environment if the header files, predefined symbols, and libraries
appear as they do on a sun3.
Nor does the host environment refer to the the machine on which
the program to be built will run. It is possible to provide a
sun3 emulation environment on a sun4 such that programs built in a
sun3 development environment actually run on the sun4.
Host environment simply refers to the environment in which the
program will be built from the source.
Configuration Time Options:
Many programs have compile time options. That is, features of the
program that are either compiled into the program or not based on a
choice made by the person who builds the program. We refer to these
as "configuration options". For example, our desk calculator might be
capable of being compiled into a program that either uses infix
notation or postfix as a configuration option. For a sun3, chosing
infix might be:
./configure sun3 +notation=infix
while a sun4 with postfix might be:
./configure sun4 +notation=postfix
If we wanted to build both at the same time, in the same directory
structure, the intermediate pieces used in the build process must
be kept separate.
./configure sun4 +subdirs +notation=postfix
./configure sun3 +subdirs +notation=infix
will create subdirectories for the intermediate pieces of the sun4
and sun3 configurations. This is necessary as previous systems
were only capable of one configuration at a time. A second
configuration overwrote the first. We've chosen to retain this
behaviour so the "+subdirs" configuration option is necessary
to get the new behaviour. The order of the arguments doesn't
matter. There should be exactly one argument without a leading
'+' sign and that argument will be assumed to be the host name.
From here on the examples will assume that you want to build the
tools "in place" and won't show the "+subdirs" option, but
remember that it is available.
In order to actually install the program, the configuration system
needs to know where you would like the program installed. The
default location is /usr/local. We refer to this location as
$(destdir). All user visible programs will be installed in
$(destdir)/bin. All other programs and files will be installed in
a subdirectory of $(destdir)/lib.
You can elect to change $(destdir) only as a configuration time
option.
./configure sun4 +notation=postfix +destdir=/local
Will configure the source such that:
make install
will put it's programs in /local/bin and /local/lib/gcc. If you
change $(destdir) after building the source, you will need to:
make clean
before the change will be propogated properly. This is because
some tools need to know the locations of other tools.
With these concepts in mind, we can drop the desk calculator and
move on to the application that resides in these directories,
namely, the source to a development environment.
SPECIFICS
---------
The GNU Development Tools can be built on a wide variety of hosts.
So, of course, they must be configured. Like the last example,
./configure sun4 +destdir=/local
./configure sun3 +destdir=/local
will configure the source to be built in subdirectories, in order
to keep the intermediate pieces separate, and to be installed in
/local.
When built with suitable development environments, these will be
native tools. We'll explain the term "native" later.
BUILDING DEVELOPMENT ENVIRONMENTS
---------------------------------
The Cygnus Support GNU development tools can not only be built
with a number of host development environments, they can also be
configured to create a number of different development
environments on each of those hosts. We refer to a specific
development environment created as a "target". That is, the word
"target" refers to the development environment produced by
compiling this source and installing the resulting programs.
For the Cygnus Support GNU development tools, the default target
is the same as the host. That is, the development environment
produced is intended to be compatible with the environment used to
build the tools.
In the example above, we created two configurations, one for sun4
and one for sun3. The first configuration is expecting to be
built in a sun4 development environment, to create a sun4
development environment. It doesn't necessarily need to be built
on a sun4 if a sun4 development environment is available
elsewhere. Likewise, if the available sun4 development
environment produces executables intended for something other than
sun4, then the development environment built from this sun4
configuration will run on something other than a sun4. From the
point of view of the configuration system and the GNU development
tools source, this doesn't matter. What matters is that they will
be built in a sun4 environment.
Similarly, the second configuration given above is expecting to be
built in a sun3 development environment, to create a sun3
development environment.
The development environment produced, is a configuration time
option, just like $(destdir).
./configure sun4 +destdir=/local +target=sun3
./configure sun3 +destdir=/local +target=sun4
In this example, like before, we create two configurations. The
first is intended to be built in a sun4 environment, in
subdirectories, to be installed in /local. The second is intended
to be built in a sun3 environment, in subdirectories, to be
installed in /local.
Unlike the previous example, the first configuration will produce
a sun3 development environment, perhaps even suitable for building
the second configuration. Likewise, the second configuration will
produce a sun4 development environment, perhaps even suitable for
building the first configuration.
The development environment used to build these configurations
will determine the machines on which the resulting development
environments can be used.
A WALK THROUGH
--------------
Native Development Environments:
Let us assume for a moment that you have a sun4 and that with your
sun4 you received a development environment. This development
environment is intended to be run on your sun4 to build programs
that can be run on your sun4. You could, for instance, run this
development environment on your sun4 to build our example desk
calculator program. You could then run the desk calculator
program on your sun4.
The resulting desk calculator program is referred to as a "native"
program. The development environment itself is composed of native
programs that, when run, build other native programs. Any other
program is referred to as "foreign". Programs intended for other
machines are foreign programs.
This type of development environment, which is by far the most
common, is refered to as "native". That is, a native development
environment runs on some machine to build programs for that same
machine. The process of using a native development environment to
build native programs is called a "native" build.
./configure sun4
Will configure this source such that when built in a sun4
development environment, with a development environment that
builds programs intended to be run on sun4 machines, the programs
built will be native programs and the resulting development
environment will be a native development environment.
The development system that came with your sun4 is one such
environment. Using it to build the GNU Development Tools is a
very common activity and the resulting development environment is
very popular.
make all
will build the tools as configured and will assume that you want
to use the native development environment that came with your
machine.
Using a development environment to build a development environment
is called "bootstrapping". The Cygnus Support release of the GNU
Development Tools is capable of bootstrapping itself. This is a
very powerful feature that we'll return to later. For now, let's
pretend that you used the native development environment that came
with your sun4 to bootstrap the Cygnus Support release and let's
call the new development environment stage1.
Why bother? Well, most people find that the Cygnus Support
release builds programs that run faster and take up less space
than the native development environments that came with their
machines. Some people didn't get development environments with
their machines and some people just like using the GNU tools
better than using other tools.
While you're at it, if the GNU tools produce better programs, maybe
you should use them to build the GNU tools. It's a good idea, so
let's pretend that you do. Let's call the new development
environment stage2.
So far you've built a development environment, stage1, and you've
used stage1 to build a new, faster and smaller development
environment, stage2, but you haven't run any of the programs that
the GNU tools have built. You really don't yet know if these
tools work. Do you have any programs built with the GNU tools?
Yes, you do. stage2. What does that program do? It builds
programs. Ok, do you have any source handy to build into a
program? Yes, you do. The GNU tools themselves. In fact, if you
use stage2 to build the GNU tools again the resulting programs
should be identical to stage2. Let's pretend that you do and call
the new development environment stage3.
You've just completed what's called a "three stage boot". You now
have a small, fast, somewhat tested, development environment.
make bootstrap
will do a three stage boot across all tools and will compare
stage2 to stage3 and complain if they are not identical.
Once built,
make install
will install the development environment in the default location
or in $(destdir) if you specified an alternate when you
configured. In fact, you can skip the "make all" part and just
"make install" which will make sure that the development
environment is built before attempting to install anything. Even
better, for configurations where host is the same as target, like
this one, "make install" will make sure that a "make bootstrap" is
done before installing anything.
Any development environment that is not a native development
environment is refered to as a "cross" development environment.
There are many different types of cross development environments
but most fall into one of FIXME basic categories.
Emulation Environments:
The first category of cross development environment is called
"emulation". There are two primary types of emulation, but both
types result in programs that run on the native host.
The first type is "software emulation". This form of cross
development environment involves a native program that when run on
the native host, is capable of interpreting, and in most aspects
running, a program intended for some other machine. This
technique is typically used when the other machine is either too
expensive, too slow, too fast, or not available, perhaps because
it hasn't yet been built. The native, interpreting program is
called a "software emulator".
The GNU Development Tools do not currently include any software
emulators. Some do exist and the GNU Development Tools can be
configured to create simple cross development environments for
with these emulators. More on this later.
The second type of emulation is when source intended for some
other development environment is built into a program intended for
the native host. The concept of universes in operating systems
and hosted operating systems are two such development
environments.
The Cygnus Support Release of the GNU Development Tools can be
configured for one such emulation at this time.
./configure sun4 +ansi
will configure the source such that when built in a sun4
development environment the resulting development environment is
capable of building sun4 programs from strictly conforming ANSI
X3J11 C source. Remember that the environment used to build the
tools determines the machine on which this tools will run, so the
resulting programs aren't necessarily intended to run on a sun4,
although they usually are. Also note that the source for the GNU
tools is not strictly conforming ANSI source so this configuration
cannot be used to bootstrap the GNU tools.
Simple Cross Environments:
./configure sun4 +target=a29k
will configure the tools such that when compiled in a sun4
development environment the resulting development environment can
be used to create programs intended for an a29k. Again, this does
not necessarily mean that the new development environment can be
run on a sun4. That would depend on the development environment
used to build these tools.
Earlier you saw how to configure the tools to build a native
development environment, that is, a development environment that
runs on your sun4 and builds programs for your sun4. Let's
pretend that you use stage3 to build this simple cross
configuration and let's call the new development environment
gcc-a29k. Remember that this is a native build. Gcc-a29k is a
collection of native programs intended to run on your sun4.
That's what stage3 builds, programs for your sun4. Gcc-a29k
represents an a29k development environment that builds programs
intended to run on an a29k. But, remember, gcc-a29k runs on your
sun4. Programs built with gcc-a29k will run on your sun4 only
with the help of an appropriate software emulator.
Building gcc-a29k is also a bootstrap but of a slightly different
sort. We call gcc-a29k a simple cross environment and using
gcc-a29k to build a program intended for a29k is called "crossing
to" a29k. Simple cross environments are the second category of
cross development environments.
Crossing Into Targets:
./configure a29k +target=a29k
will configure the tools such that when compiled in an a29k
development environment, the resulting development environment can
be used to create programs intended for an a29k. Again, this does
not necessarily mean that the new development environment can be
run on an a29k. That would depend on the development environment
used to build these tools.
If you've been following along this walk through, then you've
already built an a29k environment, namely gcc-a29k. Let's pretend
you use gcc-a29k to build the current configuration.
Gcc-a29k builds programs intended for the a29k so the new
development environment will be intended for use on an a29k. That
is, this new gcc consists of programs that are foreign to your
sun4. They cannot be run on your sun4.
The process of building this configuration is another a bootstrap.
This bootstrap is also a cross to a29k. Because this type of
build is both a bootstrap and a cross to a29k, it is sometimes
referred to as a "cross into" a29k. This new development
environment isn't really a cross development environment at all.
It is intended to run on an a29k to produce programs for an a29k.
You'll remember that this makes it, by definition, an a29k native
compiler. "Crossing into" has been introduced here not because it
is a type of cross development environment, but because it is
frequently confused one. The process is "a cross" but the
resulting development environment is a native development
environment.
You could not have built this configuration with stage3, because
stage3 doesn't provide an a29k environment. Instead it provides a
sun4 environment.
If you happen to have an a29k lying around, you could now use
this fresh development environment on the a29k to three-stage
these tools all over again. This process would look just like it
did when we built the native sun4 development environment because
we would be building another native development environment, this
one on a29k.
The Three Party Cross:
So far you've seen that our development environment source must be
configured for a specific host and for a specific target. You've
also seen that the resulting development environment depends on
the development environment used in the build process.
When all four match identically, that is, the configured host, the
configured target, the environment presented by the development
environment used in the build, and the machine on which the
resulting development environment is intended to run, then the new
development environment will be a native development environment.
When all four match except the configured host, then we can assume
that the development environment used in the build is some form of
library emulation.
When all four match except for the configured target, then the
resulting development environment will be a simple cross
development environment.
When all four match except for the host on which the development
environment used in the build runs, the build process is a "cross
into" and the resulting development environment will be native to
some other machine.
Most of the other permutations do exist in some form, but only one
more is interesting to the current discussion.
./configure a29k +target=sun3
will configure the tools such that when compiled in an a29k
development environment, the resulting development environment can
be used to create programs intended for a sun3. Again, this does
not necessarily mean that the new development environment can be
run on an a29k. That would depend on the development environment
used to build these tools.
If you are still following along, then you have two a29k
development environments, the native development environment that
runs on a29k, and the simple cross that runs on your sun4. If you
use the a29k native development environment on the a29k, you will
be doing the same thing we did a while back, namely building a
simple cross from a29k to sun3. Let's pretend that instead, you
use gcc-a29k, the simple cross development environment that runs
on sun4 but produces programs for a29k.
The resulting development environment will run on a29k because
that's what gcc-a29k builds, a29k programs. This development
environment will produce programs for a sun3 because that is how
it was configured. This means that the resulting development
environment is a simple cross.
There really isn't a common name for this process because very few
development environments are capable of being configured this
extensively. For the sake of discussion, let's call this process
a "three party cross".
FINAL NOTES
-----------
By "configures", I mean that links, Makefile, .gdbinit, and
config.status are built. Configuration is always done from the source
directory.
* "./configure name" configures this directory, perhaps recursively,
for a single host+target pair where the host and target are both
"name". If a previous configuration existed, it will be
overwritten.
* "./configure hostname +target=targetname" configures this directory,
perhaps recursively, for a single host+target pair where the host is
hostname and target is targetname. If a previous configuration
existed, it will be overwritten.
* "./configure +subdirs hostname +target=targetname" creates a
subdirectories H-hostname and H-hostname/T-targetname and
configures H-hostname/T-targetname. For now, makes should
be done from H-hostname/T-targetname. "./configure +sub name"
works as expected. That is, it creates H-name and
H-name/T-name and configures the latter.
Hacking configurations:
The configure scripts essentially do three things, create
subdirectories if appropriate, build a Makefile, and create links to
files, all based on and tailored to, a specific host+target pair. The
scripts also create a .gdbinit if appropriate but this is not
tailored.
The Makefile is created by prepending some variable definitions to a
Makefile template called Makefile.in and then inserting host and
target specific Makefile fragments. The variables are set based on
the chosen host+target pair and build style, that is, if you use
subdirectories or not. The host and target specific Makefile may or
may not exist. If fragments
* Makefiles can be edited directly, but those changes will eventually
be lost. Changes intended to be permanent for a specific host
should be made to the host specific Makefile fragment. This should
be in ./config/hmake-host if it exists. Changes intended to be
permanent for a specific target should be made to the target
specific Makefile fragment. This should be in ./config/tmake-target
if it exists. Changes intended to be permanent for the directory
should be made in Makefile.in. To propogate changes to any of
these, either use "make Makefile" or re-configure from the source
directory.
* configure can be edited directly, but those changes will eventually
be lost. Changes intended to be permanent for a specific directory
should be made to configure.in. Changes intended to be permanent
for all configure scripts should be made to configure.template.
Propogating changes to configure.in requires the presence of
configure.template which normally resides in the uppermost directory
you received. To propogate changes to either configure.template or
a configure.in, use "configure +template=pathtothetemplate".
This will configure the configure scripts themselves, recursively if
appropriate.
* "./configure -srcdir=foo" is not supported yet. At the moment, things
will probably be configured correctly only for leaf directories, and
even they will not have paths to libraries set properly.

740
cfg-paper.texi
View File

@ -1,740 +0,0 @@
\input texinfo @c -*-para-*-
@c %**start of header
@setfilename cfg-paper.info
@settitle On Configuring Development Tools
@c %**end of header
@setchapternewpage off
@ifinfo
This document attempts to describe the general concepts behind
configuration of the Cygnus Support release of the @sc{gnu} Development
Tools. It also discusses common usage..
Copyright 1991, 1992 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).
@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation approved
by Cygnus Support.
@end ifinfo
@titlepage
@sp 10
@title{On Configuring Development Tools}
@author{K. Richard Pixley, @code{rich@@cygnus.com}}
@author{Cygnus Support}
@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1991, 1992 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation approved
by Cygnus Support.
@end titlepage
@ifinfo
@format
START-INFO-DIR-ENTRY
* configuration: (cfg-paper). Some theory on configuring source.
END-INFO-DIR-ENTRY
@end format
@end ifinfo
@node top, Some Basic Terms, (dir), (dir)
@ifinfo
This document attempts to describe the general concepts behind
configuration of the Cygnus Support release of the @sc{gnu} Development
Tools. It also discusses common usage.
@end ifinfo
@menu
* Some Basic Terms:: Some Basic Terms
* Specifics.:: Specifics
* Building Development Environments:: Building Development Environments
* A Walk Through:: A Walk Through
* Final Notes:: Final Notes
* Index:: Index
--- The Detailed Node Listing ---
Some Basic Terms
* Host Environments:: Host Environments
* Configuration Time Options:: Configuration Time Options
A Walk Through
* Native Development Environments:: Native Development Environments
* Emulation Environments:: Emulation Environments
* Simple Cross Environments:: Simple Cross Environments
* Crossing Into Targets:: Crossing Into Targets
* Canadian Cross:: Canadian Cross
Final Notes
* Hacking Configurations:: Hacking Configurations
@end menu
@node Some Basic Terms, Specifics., top, top
@chapter Some Basic Terms
There are a lot of terms that are frequently used when discussing
development tools. Most of the common terms have been used for many
different concepts such that their meanings have become ambiguous to the
point of being confusing. Typically, we only guess at their meanings
from context and we frequently guess wrong.
This document uses very few terms by comparison. The intent is to make
the concepts as clear as possible in order to convey the usage and
intent of these tools.
@emph{Programs} run on @emph{machines}. Programs are very nearly always
written in @emph{source}. Programs are @emph{built} from source.
@emph{Compilation} is a process that is frequently, but not always, used
when building programs.
@cindex Programs
@cindex Machines
@cindex Source
@cindex Building
@cindex Compilation
@menu
* Host Environments:: Host Environments
* Configuration Time Options:: Configuration Time Options
@end menu
@node Host Environments, Configuration Time Options, Some Basic Terms, Some Basic Terms
@section Host Environments
@cindex host
In this document, the word @emph{host} refers to the environment in
which the source in question will be compiled. @emph{host} and
@emph{host name} have nothing to do with the proper name of your host,
like @emph{ucbvax}, @emph{prep.ai.mit.edu} or @emph{att.com}. Instead
they refer to things like @emph{sun4} and @emph{dec3100}.
Forget for a moment that this particular directory of source is the
source for a development environment. Instead, pretend that it is the
source for a simpler, more mundane, application, say, a desk calculator.
Source that can be compiled in more than one environment, generally
needs to be set up for each environment explicitly. Here we refer to
that process as configuration. That is, we configure the source for a
host.
For example, if we wanted to configure our mythical desk calculator to
compile on a SparcStation, we might configure for host sun4. With our
configuration system:
@example
cd desk-calculator ; ./configure sun4
@end example
@noindent
does the trick. @code{configure} is a shell script that sets up Makefiles,
subdirectories, and symbolic links appropriate for compiling the source
on a sun4.
The @emph{host} environment does not necessarily refer to the machine on
which the tools are built. It is possible to provide a sun3 development
environment on a sun4. If we wanted to use a cross compiler on the sun4
to build a program intended to be run on a sun3, we would configure the
source for sun3.
@example
cd desk-calculator ; ./configure sun3
@end example
@noindent
The fact that we are actually building the program on a sun4 makes no
difference if the sun3 cross compiler presents an environment that looks
like a sun3 from the point of view of the desk calculator source code.
Specifically, the environment is a sun3 environment if the header files,
predefined symbols, and libraries appear as they do on a sun3.
Nor does the host environment refer to the the machine on which the
program to be built will run. It is possible to provide a sun3
emulation environment on a sun4 such that programs built in a sun3
development environment actually run on the sun4. This technique is
often used within individual programs to remedy deficiencies in the host
operating system. For example, some operating systems do not provide
the @code{bcopy} function and so it is emulated using the
@code{memcpy} funtion.
Host environment simply refers to the environment in which the program
will be built from the source.
@node Configuration Time Options, , Host Environments, Some Basic Terms
@section Configuration Time Options
Many programs have compile time options. That is, features of the
program that are either compiled into the program or not based on a
choice made by the person who builds the program. We refer to these as
@emph{configuration options}. For example, our desk calculator might be
capable of being compiled into a program that either uses infix notation
or postfix as a configuration option. For a sun3, to choose infix you
might use:
@example
./configure sun3 -notation=infix
@end example
@noindent
while for a sun4 with postfix you might use:
@example
./configure sun4 -notation=postfix
@end example
If we wanted to build both at the same time, the intermediate pieces
used in the build process must be kept separate.
@example
mkdir ../objdir.sun4
(cd ../objdir.sun4 ; ./configure sun4 -notation=postfix -srcdir=../src)
mkdir ../objdir.sun3
(cd ../objdir.sun3 ; ./configure sun3 -notation=infix -srcdir=../src)
@end example
@noindent
will create subdirectories for the intermediate pieces of the sun4 and
sun3 configurations. This is necessary as previous systems were only
capable of one configuration at a time. Otherwise, a second
configuration would write over the first. We've chosen to retain this
behaviour so the obj directories and the @code{-srcdir} configuration
option are necessary to get the new behaviour. The order of the
arguments doesn't matter. There should be exactly one argument without
a leading @samp{-} sign and that argument will be assumed to be the host
name.
From here on the examples will assume that you want to build the tools
@emph{in place} and won't show the @code{-srcdir} option, but remember
that it is available.
In order to actually install the program, the configuration system needs
to know where you would like the program installed. The default
location is @file{/usr/local}. We refer to this location as
@code{$(prefix)}. All user visible programs will be installed in
@file{@code{$(prefix)}/bin}. All other programs and files will be
installed in a subdirectory of @file{@code{$(prefix)}/lib}.
NOTE: @code{$(prefix)} was previously known as @code{$(destdir)}.
You can elect to change @code{$(prefix)} only as a configuration time
option.
@example
./configure sun4 -notation=postfix -prefix=/local
@end example
@noindent
Will configure the source such that:
@example
make install
@end example
@noindent
will put it's programs in @file{/local/bin} and @file{/local/lib/gcc}.
If you change @code{$(prefix)} after building the source, you will need
to:
@example
make clean
@end example
@noindent
before the change will be propogated properly. This is because some
tools need to know the locations of other tools.
With these concepts in mind, we can drop the desk calculator example and
move on to the application that resides in these directories, namely,
the source to a development environment.
@node Specifics., Building Development Environments, Some Basic Terms, top
@chapter Specifics
The @sc{gnu} Development Tools can be built on a wide variety of hosts. So,
of course, they must be configured. Like the last example,
@example
./configure sun4 -prefix=/local
./configure sun3 -prefix=/local
@end example
@noindent
will configure the source to be built in subdirectories, in order to
keep the intermediate pieces separate, and to be installed in
@file{/local}.
When built with suitable development environments, these will be native
tools. We'll explain the term @emph{native} later.
@node Building Development Environments, A Walk Through, Specifics., top
@chapter Building Development Environments
@cindex Target
The Cygnus Support @sc{gnu} development tools can not only be built in a
number of host development environments, they can also be configured to
create a number of different development environments on each of those
hosts. We refer to a specific development environment created as a
@emph{target}. That is, the word @emph{target} refers to the development
environment produced by compiling this source and installing the
resulting programs.
For the Cygnus Support @sc{gnu} development tools, the default target is the
same as the host. That is, the development environment produced is
intended to be compatible with the environment used to build the tools.
In the example above, we created two configurations, one for sun4 and
one for sun3. The first configuration is expecting to be built in a
sun4 development environment, to create a sun4 development environment.
It doesn't necessarily need to be built on a sun4 if a sun4 development
environment is available elsewhere. Likewise, if the available sun4
development environment produces executables intended for something
other than sun4, then the development environment built from this sun4
configuration will run on something other than a sun4. From the point
of view of the configuration system and the @sc{gnu} development tools
source, this doesn't matter. What matters is that they will be built in
a sun4 environment.
Similarly, the second configuration given above is expecting to be built
in a sun3 development environment, to create a sun3 development
environment.
The development environment produced, is a configuration time option,
just like @code{$(prefix)}.
@example
./configure sun4 -prefix=/local -target=sun3
./configure sun3 -prefix=/local -target=sun4
@end example
In this example, like before, we create two configurations. The first
is intended to be built in a sun4 environment, in subdirectories, to be
installed in @file{/local}. The second is intended to be built in a
sun3 environment, in subdirectories, to be installed in @file{/local}.
Unlike the previous example, the first configuration will produce a sun3
development environment, perhaps even suitable for building the second
configuration. Likewise, the second configuration will produce a sun4
development environment, perhaps even suitable for building the first
configuration.
The development environment used to build these configurations will
determine the machines on which the resulting development environments
can be used.
@node A Walk Through, Final Notes, Building Development Environments, top
@chapter A Walk Through
@menu
* Native Development Environments:: Native Development Environments
* Emulation Environments:: Emulation Environments
* Simple Cross Environments:: Simple Cross Environments
* Crossing Into Targets:: Crossing Into Targets
* Canadian Cross:: Canadian Cross
@end menu
@node Native Development Environments, Emulation Environments, A Walk Through, A Walk Through
@section Native Development Environments
Let us assume for a moment that you have a sun4 and that with your sun4
you received a development environment. This development environment is
intended to be run on your sun4 to build programs that can be run on
your sun4. You could, for instance, run this development environment on
your sun4 to build our example desk calculator program. You could then
run the desk calculator program on your sun4.
@cindex Native
@cindex Foreign
The resulting desk calculator program is referred to as a @emph{native}
program. The development environment itself is composed of native
programs that, when run, build other native programs. Any other program
is referred to as @emph{foreign}. Programs intended for other machines are
foreign programs.
This type of development environment, which is by far the most common,
is refered to as @emph{native}. That is, a native development environment
runs on some machine to build programs for that same machine. The
process of using a native development environment to build native
programs is called a @emph{native} build.
@example
./configure sun4
@end example
@noindent
will configure this source such that when built in a sun4 development
environment, with a development environment that builds programs
intended to be run on sun4 machines, the programs built will be native
programs and the resulting development environment will be a native
development environment.
The development system that came with your sun4 is one such environment.
Using it to build the @sc{gnu} Development Tools is a very common activity
and the resulting development environment is quite popular.
@example
make all
@end example
@noindent
will build the tools as configured and will assume that you want to use
the native development environment that came with your machine.
@cindex Bootstrapping
@cindex Stage1
Using a development environment to build a development environment is
called @emph{bootstrapping}. The Cygnus Support release of the @sc{gnu}
Development Tools is capable of bootstrapping itself. This is a very
powerful feature that we'll return to later. For now, let's pretend
that you used the native development environment that came with your
sun4 to bootstrap the Cygnus Support release and let's call the new
development environment @emph{stage1}.
Why bother? Well, most people find that the @sc{gnu} development
environment builds programs that run faster and take up less space than
the native development environments that came with their machines. Some
people didn't get development environments with their machines and some
people just like using the @sc{gnu} tools better than using other tools.
@cindex Stage2
While you're at it, if the @sc{gnu} tools produce better programs, maybe you
should use them to build the @sc{gnu} tools. It's a good idea, so let's
pretend that you do. Let's call the new development environment
@emph{stage2}.
@cindex Stage3
So far you've built a development environment, stage1, and you've used
stage1 to build a new, faster and smaller development environment,
stage2, but you haven't run any of the programs that the @sc{gnu} tools have
built. You really don't yet know if these tools work. Do you have any
programs built with the @sc{gnu} tools? Yes, you do. stage2. What does
that program do? It builds programs. Ok, do you have any source handy
to build into a program? Yes, you do. The @sc{gnu} tools themselves. In
fact, if you use stage2 to build the @sc{gnu} tools again the resulting
programs should be identical to stage2. Let's pretend that you do and
call the new development environment @emph{stage3}.
@cindex Three stage boot
You've just completed what's called a @emph{three stage boot}. You now have
a small, fast, somewhat tested, development environment.
@example
make bootstrap
@end example
@noindent
will do a three stage boot across all tools and will compare stage2 to
stage3 and complain if they are not identical.
Once built,
@example
make install
@end example
@noindent
will install the development environment in the default location or in
@code{$(prefix)} if you specified an alternate when you configured.
@cindex Cross
Any development environment that is not a native development environment
is refered to as a @emph{cross} development environment. There are many
different types of cross development environments but most fall into one
of three basic categories.
@node Emulation Environments, Simple Cross Environments, Native Development Environments, A Walk Through
@section Emulation Environments
@cindex Emulation
The first category of cross development environment is called
@emph{emulation}. There are two primary types of emulation, but both
types result in programs that run on the native host.
@cindex Software emulation
@cindex Software emulator
The first type is @emph{software emulation}. This form of cross
development environment involves a native program that when run on the
native host, is capable of interpreting, and in most aspects running, a
program intended for some other machine. This technique is typically
used when the other machine is either too expensive, too slow, too fast,
or not available, perhaps because it hasn't yet been built. The native,
interpreting program is called a @emph{software emulator}.
The @sc{gnu} Development Tools do not currently include any software
emulators. Some do exist and the @sc{gnu} Development Tools can be
configured to create simple cross development environments for with
these emulators. More on this later.
The second type of emulation is when source intended for some other
development environment is built into a program intended for the native
host. The concepts of operating system universes and hosted operating
systems are two such development environments.
The Cygnus Support Release of the @sc{gnu} Development Tools can be
configured for one such emulation at this time.
@example
./configure sun4 -ansi
@end example
@cindex ANSI
@cindex X3J11
@noindent
will configure the source such that when built in a sun4 development
environment the resulting development environment is capable of building
sun4 programs from strictly conforming @sc{ANSI X3J11 C} source.
Remember that the environment used to build the tools determines the
machine on which this tools will run, so the resulting programs aren't
necessarily intended to run on a sun4, although they usually are. Also
note that the source for the @sc{gnu} tools is not strictly conforming
@sc{ansi} source so this configuration cannot be used to bootstrap the
@sc{gnu} tools.
@node Simple Cross Environments, Crossing Into Targets, Emulation Environments, A Walk Through
@section Simple Cross Environments
@example
./configure sun4 -target=a29k
@end example
@noindent
will configure the tools such that when compiled in a sun4 development
environment the resulting development environment can be used to create
programs intended for an a29k. Again, this does not necessarily mean
that the new development environment can be run on a sun4. That would
depend on the development environment used to build these tools.
Earlier you saw how to configure the tools to build a native development
environment, that is, a development environment that runs on your sun4
and builds programs for your sun4. Let's pretend that you use stage3 to
build this simple cross configuration and let's call the new development
environment gcc-a29k. Remember that this is a native build. Gcc-a29k
is a collection of native programs intended to run on your sun4. That's
what stage3 builds, programs for your sun4. Gcc-a29k represents an a29k
development environment that builds programs intended to run on an a29k.
But, remember, gcc-a29k runs on your sun4. Programs built with gcc-a29k
will run on your sun4 only with the help of an appropriate software
emulator.
@cindex Simple cross
@cindex Crossing to
Building gcc-a29k is also a bootstrap but of a slightly different sort.
We call gcc-a29k a @emph{simple cross} environment and using gcc-a29k to
build a program intended for a29k is called @emph{crossing to} a29k.
Simple cross environments are the second category of cross development
environments.
@node Crossing Into Targets, Canadian Cross, Simple Cross Environments, A Walk Through
@section Crossing Into Targets
@example
./configure a29k -target=a29k
@end example
@noindent
will configure the tools such that when compiled in an a29k development
environment, the resulting development environment can be used to create
programs intended for an a29k. Again, this does not necessarily mean
that the new development environment can be run on an a29k. That would
depend on the development environment used to build these tools.
If you've been following along this walk through, then you've already
built an a29k environment, namely gcc-a29k. Let's pretend you use
gcc-a29k to build the current configuration.
Gcc-a29k builds programs intended for the a29k so the new development
environment will be intended for use on an a29k. That is, this new gcc
consists of programs that are foreign to your sun4. They cannot be run
on your sun4.
@cindex Crossing into
The process of building this configuration is another a bootstrap. This
bootstrap is also a cross to a29k. Because this type of build is both a
bootstrap and a cross to a29k, it is sometimes referred to as a
@emph{cross into} a29k. This new development environment isn't really a
cross development environment at all. It is intended to run on an a29k
to produce programs for an a29k. You'll remember that this makes it, by
definition, an a29k native compiler. @emph{Crossing into} has been
introduced here not because it is a type of cross development
environment, but because it is frequently mistaken as one. The process
is @emph{a cross} but the resulting development environment is a native
development environment.
You could not have built this configuration with stage3, because stage3
doesn't provide an a29k environment. Instead it provides a sun4
environment.
If you happen to have an a29k lying around, you could now use this fresh
development environment on the a29k to three-stage these tools all over
again. This process would look just like it did when we built the
native sun4 development environment because we would be building another
native development environment, this one on a29k.
@node Canadian Cross, , Crossing Into Targets, A Walk Through
@section Canadian Cross
So far you've seen that our development environment source must be
configured for a specific host and for a specific target. You've also
seen that the resulting development environment depends on the
development environment used in the build process.
When all four match identically, that is, the configured host, the
configured target, the environment presented by the development
environment used in the build, and the machine on which the resulting
development environment is intended to run, then the new development
environment will be a native development environment.
When all four match except the configured host, then we can assume that
the development environment used in the build is some form of library
emulation.
When all four match except for the configured target, then the resulting
development environment will be a simple cross development environment.
When all four match except for the host on which the development
environment used in the build runs, the build process is a @emph{cross into}
and the resulting development environment will be native to some other
machine.
Most of the other permutations do exist in some form, but only one more
is interesting to the current discussion.
@example
./configure a29k -target=sun3
@end example
@noindent
will configure the tools such that when compiled in an a29k development
environment, the resulting development environment can be used to create
programs intended for a sun3. Again, this does not necessarily mean
that the new development environment can be run on an a29k. That would
depend on the development environment used to build these tools.
If you are still following along, then you have two a29k development
environments, the native development environment that runs on a29k, and
the simple cross that runs on your sun4. If you use the a29k native
development environment on the a29k, you will be doing the same thing we
did a while back, namely building a simple cross from a29k to sun3.
Let's pretend that instead, you use gcc-a29k, the simple cross
development environment that runs on sun4 but produces programs for
a29k.
The resulting development environment will run on a29k because that's
what gcc-a29k builds, a29k programs. This development environment will
produce programs for a sun3 because that is how it was configured. This
means that the resulting development environment is a simple cross.
@cindex Canadian Cross
@cindex Three party cross
There really isn't a common name for this process because very few
development environments are capable of being configured this
extensively. For the sake of discussion, let's call this process a
@emph{Canadian cross}. It's a three party cross, Canada has a three
party system, hence Canadian Cross.
@node Final Notes, Index, A Walk Through, top
@chapter Final Notes
By @emph{configures}, I mean that links, Makefile, .gdbinit, and
config.status are built. Configuration is always done from the source
directory.
@table @code
@item ./configure @var{name}
configures this directory, perhaps recursively, for a single host+target
pair where the host and target are both @var{name}. If a previous
configuration existed, it will be overwritten.
@item ./configure @var{hostname} -target=@var{targetname}
configures this directory, perhaps recursively, for a single host+target
pair where the host is @var{hostname} and target is @var{targetname}.
If a previous configuration existed, it will be overwritten.
@end table
@menu
* Hacking Configurations:: Hacking Configurations
@end menu
@node Hacking Configurations, , Final Notes, Final Notes
@section Hacking Configurations
The configure scripts essentially do three things, create subdirectories
if appropriate, build a @file{Makefile}, and create links to files, all
based on and tailored to, a specific host+target pair. The scripts also
create a @file{.gdbinit} if appropriate but this is not tailored.
The Makefile is created by prepending some variable definitions to a
Makefile template called @file{Makefile.in} and then inserting host and
target specific Makefile fragments. The variables are set based on the
chosen host+target pair and build style, that is, if you use
@code{-srcdir} or not. The host and target specific Makefile may or may
not exist.
@itemize @bullet
@item
Makefiles can be edited directly, but those changes will eventually be
lost. Changes intended to be permanent for a specific host should be
made to the host specific Makefile fragment. This should be in
@file{./config/mh-@var{host}} if it exists. Changes intended to be
permanent for a specific target should be made to the target specific
Makefile fragment. This should be in @file{./config/mt-@var{target}} if
it exists. Changes intended to be permanent for the directory should be
made in @file{Makefile.in}. To propogate changes to any of these,
either use @code{make Makefile} or @code{./config.status} or
re-configure.
@end itemize
@page
@node Index, , Final Notes, top
@appendix Index
@printindex cp
@contents
@bye
@c Local Variables:
@c fill-column: 72
@c End:

575
config.subr
View File

@ -1,575 +0,0 @@
#!/bin/sh
# Configuration validation subroutine script, version 1.0.
# Copyright (C) 1991 Free Software Foundation, Inc.
#This file is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 2 of the License, or
#(at your option) any later version.
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#You should have received a copy of the GNU General Public License
#along with this program; if not, write to the Free Software
#Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
# Configuration subroutine to validate and canonicalize a configuration type.
# Supply the specified configuration type as an argument.
# If it is invalid, we print an error message on stderr and exit with code 1.
# Otherwise, we print the canonical config type on stdout and succeed.
# This file is supposed to be the same for all GNU packages
# and recognize all the CPU types, system types and aliases
# that are meaningful with *any* GNU software.
# Each package is responsible for reporting which valid configurations
# it does not support. The user should be able to distinguish
# a failure to support a valid configuration from a meaningless
# configuration.
# The goal of this file is to map all the various variations of a given
# machine specification into a single specification in the form:
# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# it is wrong to echo any other type of specification
# First pass through any local machine types.
case $1 in
*local*)
echo $1
exit 0
;;
*)
;;
esac
# Separate what the user gave into CPU-COMPANY and OS (if any).
basic_machine=`echo $1 | sed 's/-[^-]*$//'`
if [ $basic_machine != $1 ]
then os=`echo $1 | sed 's/.*-/-/'`
else os=; fi
# Lets recognize common machines as not being OS so that things like
# config.subr decstation-3100 as legal.
case $os in
-dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \
-att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \
-unicom* | -ibm* | -next* | -hp | -isi* | -apollo | -altos* | \
-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -osf* | \
-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
-harris)
os=
basic_machine=$1
;;
-sco*)
os=-scosysv322
basic_machine=i386-unknown
;;
-isc*)
os=-iscsysv
basic_machine=i386-unknown
;;
# start-sanitize-v9
-32)
basic_machine=sparc64-hal
os=-hal32
;;
-64)
basic_machine=sparc64-hal
os=-hal64
;;
-v7)
basic_machine=sparc64-hal
os=-v7
;;
# end-sanitize-v9
esac
# Decode aliases for certain CPU-COMPANY combinations.
case $basic_machine in
# Recognize the basic CPU types with without company name.
tahoe | i386 | i860 | m68k | m68000 | m88k | ns32k | arm | pyramid \
| tron | a29k | 580 | i960 | h8300)
basic_machine=$basic_machine-unknown
;;
# Recognize the basic CPU types with with company name.
vax-* | tahoe-* | i386-* | i860-* | m68k-* | m68000-* | m88k-* \
| sparc-* | ns32k-* | alliant-* | arm-* | c[123]* \
| mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
| none-* | 580-* | cray2-* | h8300-* | i960-* | xmp-* | ymp-* \
| hppa-*)
;;
# Recognize the various machine names and aliases which stand
# for a CPU type and a company and sometimes even an OS.
# start-sanitize-life
life-*) ;;
life)
basic_machine=life-philips
os=-none
;;
# end-sanitize-life
# start-sanitize-v9
sparc64-*) ;;
hal-32 | hal32)
basic_machine=sparc64-hal
os=-hal32
;;
hal-64 | hal64)
basic_machine=sparc64-hal
os=-hal64
;;
sparc64)
basic_machine=sparc64-sun
os=-v9
;;
sparc64-v7 | sparc64v7)
basic_machine=sparc64-sun
os=-v7
;;
# end-sanitize-v9
vaxv)
basic_machine=vax-dec
os=-sysv
;;
vms)
basic_machine=vax-dec
os=-vms
;;
i386v32)
basic_machine=i386-unknown
os=-sysv32
;;
i386-sco* | i386sco | sco)
basic_machine=i386-unknown
os=-scosysv322
;;
i386-isc* | isc)
basic_machine=i386-unknown
os=-iscsysv
;;
i386v4*)
basic_machine=i386-unknown
os=-sysv4
;;
i386v)
basic_machine=i386-unknown
os=-sysv
;;
spur)
basic_machine=spur-unknown
;;
alliant)
basic_machine=alliant-alliant
;;
convex-c1)
basic_machine=c1-convex
os=-sysv
;;
convex-c2)
basic_machine=c2-convex
os=-sysv
;;
convex-c32)
basic_machine=c32-convex
os=-sysv
;;
convex-c34)
basic_machine=c34-convex
os=-sysv
;;
convex-c38)
basic_machine=c38-convex
os=-sysv
;;
m88k-omron*)
basic_machine=m88k-omron
;;
merlin)
basic_machine=ns32k-utek
os=-sysv
;;
crds | unos)
basic_machine=m68k-crds
;;
encore | umax | mmax)
basic_machine=ns32k-encore
os=-sysv
;;
genix)
basic_machine=ns32k-ns
;;
iris | iris4d)
basic_machine=mips-sgi
os=-irix
;;
news | news700 | news800 | news900)
basic_machine=m68k-sony
os=-newsos
;;
3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc)
basic_machine=m68k-att
;;
delta | 3300 | motorola-3300 | motorola-delta \
| 3300-motorola | delta-motorola)
basic_machine=m68k-motorola
;;
balance)
basic_machine=ns32k-sequent
os=-dynix
;;
pc532)
basic_machine=ns32k-pc532
;;
symmetry)
basic_machine=i386-sequent
os=-dynix
;;
sun2)
basic_machine=m68000-sun
;;
sun2os3)
basic_machine=m68000-sun
os=-sunos3
;;
sun2os4)
basic_machine=m68000-sun
os=-sunos4
;;
sun3os3)
basic_machine=m68k-sun
os=-sunos3
;;
sun3os4)
basic_machine=m68k-sun
os=-sunos4
;;
sun4os3)
basic_machine=sparc-sun
os=-sunos3
;;
sun4os4)
basic_machine=sparc-sun
os=-sunos4
;;
sun3)
basic_machine=m68k-sun
;;
sun4)
basic_machine=sparc-sun
;;
pbd)
basic_machine=sparc-unicom
;;
sun386 | sun386i | roadrunner)
basic_machine=i386-sun
;;
ps2)
basic_machine=i386-ibm
;;
next)
basic_machine=m68k-next
os=-sysv
;;
hp9k3[2-9][0-9])
basic_machine=m68k-hp
;;
hp9k31[0-9] | hp9k2[0-9][0-9])
basic_machine=m68000-hp
;;
hp9k8[0-9][0-9] | hp9k7[0-9][0-9] | hp8[0-9][0-9] | hp7[0-9][0-9])
basic_machine=hp800-hp
;;
isi68 | isi)
basic_machine=m68k-isi
os=-sysv
;;
apollo68)
basic_machine=m68k-apollo
os=-sysv
;;
altos | altos3068)
basic_machine=m68k-altos
;;
miniframe)
basic_machine=m68000-convergent
;;
tower | tower-32)
basic_machine=m68k-ncr
;;
news-3600 | risc-news)
basic_machine=mips-sony
os=-newsos
;;
decstation-dec | decstation | decstation-3100 | pmax | pmin | dec3100 | decstatn)
basic_machine=mips-dec
;;
magnum | m3230)
basic_machine=mips-mips
os=-sysv
;;
gmicro)
basic_machine=tron-gmicro
os=-sysv
;;
rtpc | rtpc-*)
basic_machine=romp-ibm
;;
am29k)
basic_machine=a29k-none
os=-bsd
;;
amdahl)
basic_machine=580-amdahl
os=-sysv
;;
amigados)
basic_machine=m68k-cbm
os=-amigados
;;
amigaunix | amix)
basic_machine=m68k-cbm
os=-sysv4
;;
cray | ymp)
basic_machine=ymp-cray
os=-unicos
;;
cray2)
basic_machine=cray2-cray
os=-unicos
;;
xmp)
basic_machine=xmp-cray
os=-unicos
;;
delta88)
basic_machine=m88k-motorola
os=-m88kbcs
;;
dpx2)
basic_machine=m68k-bull
os=-sysv
;;
ebmon29k)
basic_machine=a29k-amd
os=-ebmon
;;
h8300hds)
basic_machine=h8300-hitachi
os=-hds
;;
harris)
basic_machine=m88k-harris
os=-m88kbcs
;;
hp300bsd)
basic_machine=m68k-hp
os=-bsd
;;
hp300hpux)
basic_machine=m68k-hp
os=-hpux
;;
hp9k2[0-9][0-9] | hp9k31[0-9])
basic_machine=m68000-hp
os=-hpux
;;
hp9k3[2-9][0-9])
basic_machine=m68k-hp
os=-hpux
;;
ncr3000)
basic_machine=i386-ncr
os=-sysv4
;;
news1000)
basic_machine=m68030-sony
os=-newsos
;;
nindy960)
basic_machine=i960-intel
os=-nindy
;;
pn)
basic_machine=pn-gould
os=-sysv
;;
np1)
basic_machine=np1-gould
os=-sysv
;;
ultra3)
basic_machine=a29k-nyu
# Is sym1 really a different system, or is it really sysv?
# os=-sym1
;;
vxworks960)
basic_machine=i960-wrs
os=-vxworks
;;
vxworks68)
basic_machine=m68k-wrs
os=-vxworks
;;
none)
basic_machine=none-none
os=-none
;;
# Here we handle the default manufacturer of certain CPU types. It is in
# some cases the only manufacturer, in others, it is the most popular.
mips)
basic_machine=mips-mips
;;
romp)
basic_machine=romp-ibm
;;
rs6000)
basic_machine=rs6000-ibm
;;
vax)
basic_machine=vax-dec
;;
sparc)
basic_machine=sparc-sun
;;
*)
echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
exit 1
;;
esac
# Decode manufacturer-specific aliases for certain operating systems.
if [ "$os" ]
then
case $os in
# First accept the basic system types.
# The portable systems comes first.
# Each alternative must end in a *, to match a version number.
-bsd* | -sysv* | -mach* | -minix* | -genix* | -ultrix* \
| -vms* | -sco* | -esix* | -isc* | -aix* | -sunos* | -hpux* \
| -unos* | -osf* | -v88r* | -luna* | -dgux* | -solari* \
| -amigados* | -msdos* \
| -nindy* | -vxworks* | -ebmon* | -hds* | -m88kbcs*)
;;
# start-sanitize-v9
-v7 | -v9 | -hal32 | -hal64) ;;
# end-sanitize-v9
-newsos*)
os=-bsd
;;
-osfrose*)
os=-osf
;;
-osf*)
os=-bsd
;;
-dynix*)
os=-bsd
;;
-aos*)
os=-bsd
;;
-ctix* | -irix* | -uts*)
os=-sysv
;;
*)
# Get rid of the `-' at the beginning of $os.
os=`echo $1 | sed 's/[^-]*-//'`
echo Invalid configuration \`$1\': system \`$os\' not recognized 1>&2
exit 1
;;
esac
else
# Here we handle the default operating systems that come with various machines.
# The value should be what the vendor currently ships out the door with their
# machine or put another way, the most popular os provided with the machine.
case $basic_machine in
*-dec | vax-*)
os=-ultrix42
;;
i386-sun)
os=-sunos402
;;
m68000-sun)
os=-sunos3
# This also exists in the configure program, but was not the
# default.
# os=-sunos4
;;
sparc-* | *-sun)
os=-sunos411
;;
romp-*)
os=-bsd
;;
*-ibm)
os=-aix
;;
*-hp)
os=-hpux
;;
*-sgi | i860-* | *-att | *-ncr | *-altos | *-motorola | *-convergent)
os=-sysv
;;
*-dg)
os=-dgux
;;
m88k-omron*)
os=-luna
;;
*-crds)
os=-unos
;;
*-ns)
os=-genix
;;
i386-*)
os=-scosysv322
;;
*)
os=-none
;;
esac
fi
# Here we handle the case where we know the os, and the CPU type, but not the
# manufacturer. We pick the logical manufacturer.
vendor=unknown
case $basic_machine in
*-unknown)
case $os in
-sunos*)
vendor=sun
;;
-aix*)
vendor=ibm
;;
-hpux*)
vendor=hp
;;
-unos*)
vendor=crds
;;
-dgux*)
vendor=dg
;;
-luna*)
vendor=omron
;;
-genix*)
vendor=ns
;;
esac
basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"`
;;
esac
echo $basic_machine$os

14
configdj.bat
View File

@ -1,14 +0,0 @@
@echo off
cd bfd
call configdj
cd ..\binutils
call configdj
cd ..\bison
call configdj
cd ..\gas
call configdj
cd ..\gcc
call configdj
cd ..\libiberty
call configdj
cd ..

118
configure.man
View File

@ -1,118 +0,0 @@
.\" -*- nroff -*-
.\" Copyright 1991, 1992 Free Software Foundation, Inc.
.\" written by K. Richard Pixley
.TH configure 1 "13 December 1991" "cygnus support" "Cygnus Support"
.de BP
.sp
.ti \-.2i
\(**
..
.SH NAME
configure \(em\& prepare source code to be built
.SH SYNOPSIS
configure host1 [host2 [host3 ...]] [-exec_prefix=dir] [-gas] [-help]
[-host=h] [-nfp] [-norecursion]
[-prefix=dir] [-s] [-rm] [-site=s] [-srcdir=dir]
[-target=t] [-v] [-x]
.SH DESCRIPTION
.I Configure
is a program used to prepare souce code to be built. It does this by
generating Makefiles and .gdbinit files, creating symlinks, digging
directories, and some other miscellaneous file editting.
.SH OPTIONS
.I Configure
accepts the following options:
.TP
.I \-exec_prefix=dir
sets the root directory for host dependent files to
.I dir.
The default location is the same as
.I prefix.
.TP
.I \-gas
tells configure that the GNU assembler is available on this machine
even if it is not ordinarily.
.TP
.I \-help
displays a brief summary of the calling convention.
.TP
.I \-host=h
asks configure to prepare the source to be compiled in an environment
called
.I h.
This option is very confusing and is best ignored. FIXME: I don't
think it should even be documented.
.TP
.I \-nfp
Notifies configure that all of the specified hosts have
.I no floating point
units.
.TP
.I \-norecursion
asks that only the current directory be configured. Normally
configure recurs on subdirectories.
.TP
.I \-prefix=dir
sets the default location in which to install files to dir. The
default is "/usr/local".
.TP
.I \-s
used internally by configure to supress status messages on
subdirectory recursions.
.TP
.I \-rm
asks configure to remove a configuration rather than creating one.
.TP
.I \-site=s
asks configure to use any site specific Makefile fragments for s when
building Makefiles.
.TP
.I \-srcdir=dir
tells configure to find the source in srcdir.
.TP
.I \-target=t
Requests that the sources be configured to target the t machine. If
no targets are specified explicitly, the target is assumed to be the
same as the host.
.TP
.I \-tmpdir=dir
Sets the directory in which configure creates temporary files to
tmpdir.
.TP
.I \-verbose
.I \-v
Asks that configure print status lines for each directory configured.
Normally, only the status lines for the current directory are printed.
.TP
.I \-x
Tells configure that MIT style X11 header files and libraries are
available on this machine, even if they are not normally available.
.SH FILES
configure.in for each directory's individual needs
config.sub for parsing configuration names
.SH "SEE ALSO"
.RB "`\|" configure "\|'"
entry in
.B
info. (not yet available).

1367
configure.texi
View File

File diff suppressed because it is too large Load Diff

1709
solaris-inst.texinfo
View File

File diff suppressed because it is too large Load Diff

1446
standards.texi
View File

File diff suppressed because it is too large Load Diff