-
-
On Configuring Development Tools
- Last Mod Sat Apr 13 19:45:44 PDT 1991, by rich@sendai
+ 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. For a more in succint
- description, please refer to the man page on "configure" which you
- should have received {FIXME: ALONG WITH LOTS OF OTHER VERY PRETTY
- HARD COPY OR IN A DIFFERENT DISTRIBUTION OR ON THIS TAPE OR SHRINK
- BOX OR SOMETHING}.
+ Tools. It also discusses common usage. Eventually, FIXME, there
+ will also be a man page for "configure", an "info" tree, etc.
BASICS
calculator to compile on a SparcStation, we might configure for
host sun4. With our configuration system:
- cd desk-calculator ; configure sun4
+ cd desk-calculator ; ./configure sun4
does the trick. "configure" is a shell script that sets up
Makefiles, subdirectories, and symbolic links appropriate for
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
+ 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
notation or postfix as a configuration option. For a sun3, chosing
infix might be:
- configure sun3 +notation=infix
+ ./configure sun3 +notation=infix
while a sun4 with postfix might be:
- configure sun4 +notation=postfix
+ ./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 +forcesubdirs +notation=postfix
- configure sun3 +forcesubdirs +notation=infix
+ ./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 "+forcesubdirs" configuration option is necessary
+ 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 "+forcesubdirs" option, but
+ 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
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. For the tools in this
- directory, the files not normally user visible will be installed
- in $(destdir)/lib/gcc.
+ a subdirectory of $(destdir)/lib.
You can elect to change $(destdir) only as a configuration time
option.
- configure sun4 +notation=postfix +destdir=/local
+ ./configure sun4 +notation=postfix +destdir=/local
Will configure the source such that:
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
+ ./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
The development environment produced, is a configuration time
option, just like $(destdir).
- configure sun4 +destdir=/local +target=sun3
- configure sun3 +destdir=/local +target=sun4
+ ./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 also
- intended to be build in a sun4 environment, in subdirectories, to
- be installed in /local.
+ 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
machine. The process of using a native development environment to
build native programs is called a "native" build.
- configure sun4
+ ./configure sun4
Will configure this source such that when built in a sun4
development environment, with a development environment that
The Cygnus Support Release of the GNU Development Tools can be
configured for one such emulation at this time.
- configure sun4 +ansi
+ ./configure sun4 +ansi
will configure the source such that when built in a sun4
development environment the resulting development environment is
Simple Cross Environments:
- configure sun4 +target=a29k
+ ./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 a sun3. Again, this does
+ 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.
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
- presents an a29k development environment that builds programs
+ represents an a29k development environment that builds programs
intended to run on an a29k. But, remember, gcc-a29k runs on your
- sun4.
+ 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
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".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- if configured for host sun4 and target sun4, this implies that we
- will compile on a sun4 to create a sun4 compilation environment.
- If configured for host sun3 and target a29k, this implies that we
- will compile on a sun3 to create an a29k compilation environment.
-
- Host sun3 only implies that the source will be compiled on a sun3.
- In fact, it need not be actually compiled on a sun3. If the
- appropriate native development tools, header files, libraries, and
- operating system support were available on a foobox, then source
- configured for a sun3 could be compiled on a foobox, resulting in
- a development environment for, using the previous example
- host+target pair, "a29k" on the foobox. Similarly, if the
- appropriate cross development tools, header files, and libraries
- were available on a dec3100, then source configured for host sun3
- could be cross compiled to create an a29k development environment
- intended to be run on a sun3.
-
-
-Usage:
-
-Gdb's config has features not yet present in the uniform configuration
-scheme described here. For this reason, configuration of gdb must
-currently be done separately from that of the rest of this package.
-This will be corrected soon. For more information on the
-configuration of gdb, please refer to the documents in gdb.{your
-target} if it exists, otherwise gdb.
+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
+* "./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 +host=hostname 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 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 +forcesubdirs +host=hostname targetname" creates
- a subdirectories Host-hostname and
- Host-hostname/Target-targetname and configures
- Host-hostname/Target-targetname. For now, makes should be
- done from Host-hostname/Target-targetname. "./configure +f
- name" works as expected. That is, it creates Host-name and
- Host-name/Target-name and configures the latter.
+* "./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:
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
+subdirectories or not. The host and target specific Makefile may or
+may not exist. If fragments
-* Makefiles can be editted directly, but those changes will eventually
+* 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
these, either use "make Makefile" or re-configure from the source
directory.
-* configure can be editted directly, but those changes will eventually
+* 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=absolutepathtothetemplate".
+ 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
+* "./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.
projects / deliverable / binutils-gdb.git / blobdiff