Resolve other problems that dumb cvs can't find out by itself.

(trivial part done, `interesting' patches remain)

6 files changed, 0 insertions, 4373 deletions

diff --git a/gnu/usr.bin/binutils/etc/ChangeLog b/gnu/usr.bin/binutils/etc/ChangeLog
deleted file mode 100644
index 8b139b28e52..00000000000
--- a/gnu/usr.bin/binutils/etc/ChangeLog
+++ /dev/null
@@ -1,322 +0,0 @@
-Wed Oct 23 00:34:07 1996  Angela Marie Thomas (angela@cygnus.com)
-
-	* Lots of patches from progressive...
- 	* Install.in: restore DDOPTS for AIX 4.x
- 	* Install.in, subst-strings: add case for DG Aviion
- 	* subst-strings: fix typo in INSTALLdir var setting
- 	* comp-tools-verify: set SHLIB_PATH for shared libs
- 	* Install.in, subst-strings:  add case for solaris2.5
- 	* Install.in: fix regression for hppa1.1 check
- 	* comp-tools-fix: set LD_LIBRARY_PATH
- 	* comp-tools-fix: If fixincludes fixes /usr/include/limits.h,
- 	install it as syslimits.h.
-
-Wed Oct 16 19:20:42 1996  Michael Meissner  <meissner@tiktok.cygnus.com>
-
-	* Install.in (guess_system): Treat powerpc-ibm-aix4.1 the same as
-	rs6000-ibm-aix4.1, since the compiler now uses common mode by
-	default.
-
-Wed Oct  2 15:39:07 1996  Jason Molenda  (crash@godzilla.cygnus.co.jp)
-
-	* configure.in (AC_PROG_INSTALL): Added.
-	* Makefile.in (distclean): Remove config.cache.
-
-Wed Oct  2 14:33:58 1996  Jason Molenda  (crash@godzilla.cygnus.co.jp)
-
-	* configure.in: Switch to autoconf configure.in.
-	* configure: New.
-	* Makefile.in: Use autoconf-substituted values.
-
-Tue Jun 25 18:56:08 1996  Jason Molenda  (crash@godzilla.cygnus.co.jp)
-
-	* Makefile.in (datadir): Changed to $(prefix)/share.
-
-Fri Mar 29 11:38:01 1996  J.T. Conklin  (jtc@lisa.cygnus.com)
-
-	* configure.man: Changed to be recognized by catman -w on Solaris.
-
-Wed Dec  6 15:40:28 1995  Doug Evans  <dje@canuck.cygnus.com>
-
-	* comp-tools-fix (fixincludes): Define FIXPROTO_DEFINES from
-	.../install-tools/fixproto-defines.
-
-Sun Nov 12 19:31:27 1995  Jason Molenda  (crash@phydeaux.cygnus.com)
-
-	* comp-tools-verify (verify_cxx_initializers): delete argv,
-	argc declarations, add -static to compile line.
-	(verify_cxx_hello_world): delete argv, argc declarations, add
-	-static to compile line.
-
-Wed Sep 20 13:21:52 1995  Ian Lance Taylor  <ian@cygnus.com>
-
-	* Makefile.in (maintainer-clean): New target, synonym for
-	realclean.
-
-Thu Sep 14 17:19:58 1995  Jason Molenda  (crash@phydeaux.cygnus.com)
-
-	* Install.in (show_exec_prefix_msg): print out paths for
-	TCL_LIBRARY, TK_LIBRARY and GDBTK_FILENAME.
-
-Mon Aug 28 17:25:49 1995  Jason Molenda  (crash@phydeaux.cygnus.com)
-
-	* Install.in (PATH):  add /usr/ucb to $PATH (for SunOS 4.1.x).
-
-Tue Aug 15 21:51:58 1995  Jason Molenda  (crash@phydeaux.cygnus.com)
-
-	* Install.in (guess_system): Match OSF/1 v3.x as the same as 
-        v2.x--v2.x binaries are upward compatible.
-
-Tue Aug 15 21:46:54 1995  Jason Molenda  (crash@phydeaux.cygnus.com)
-
-	* Install.in (guess_system): recognize HP 9000/800 systems as the
-	same as HP 9000/700 systems.
-
-Tue Aug  8 13:11:56 1995  Brendan Kehoe  <brendan@lisa.cygnus.com>
-
-	* Install.in: For emacs, run show_emacs_alternate_msg and exit.
-	(show_emacs_alternate_msg): New message saying how emacs can't be
-	installed in an alternate prefix.
-
-Thu Jun  8 00:42:56 1995  Angela Marie Thomas  <angela@cirdan.cygnus.com>
-
-        * subst-strings: change du commands to $BINDIR/. & $SRCDIR/. just
-        in case they are symlinks.
-
-Tue Apr 18 14:23:10 1995  J.T. Conklin  <jtc@rtl.cygnus.com>
-
-	* cdk-fix: Extracted table of targets that don't need their
-	  headers fixed from gcc's configure script.
-
-	* cdk-fix, cdk-verify: Use ${HOST} instead of ||HOSTstr||
-
-	* cdk-fix, cdk-verify: New files, install script fragments used
-	  for Cygnus Developer's Kit.
-
-	* Install.in (do_mkdir): New function.
-
-	* Install.in: Added support for --with and --without options.
-	  Changed so that tape commands are not run when extracting 
-	  from a file.
-	  (do_mt): Changed to take only one argument.
-
-Wed Mar 29 11:16:38 1995  Jason Molenda (crash@phydeaux.cygnus.com)
-
-	* Install.in: catch UNAME==alpha-dec-osf2.x and correct entry for
-	alpha-dec-osf1.x
-	
-Fri Jan 27 12:04:29 1995  J.T. Conklin  <jtc@rtl.cygnus.com>
-
-	* subst-strings (mips-sgi-irix5): New entry in table.
-
-Thu Jan 19 12:15:44 1995  J.T. Conklin  <jtc@rtl.cygnus.com>
-
-	* Install.in: Major rewrite, bundle dependent code (for example,
-	  fixincludes for comp-tools) will be inserted into the Install
-	  script when it is generated.
-
-Tue Jan 17 16:51:32 1995  Ian Lance Taylor  <ian@sanguine.cygnus.com>
-
-	* Makefile.in (Makefile): Rebuild using $(SHELL).
-
-Thu Nov  3 19:30:33 1994  Ken Raeburn  <raeburn@cujo.cygnus.com>
-
-	* Makefile.in (install-info): Depend on info.
-
-Fri Aug 19 16:16:38 1994  Jason Molenda     (crash@phydeaux.cygnus.com)
-
-	* Install.in: set $FIX_HEADER so fixproto can find fix-header.
-
-Fri May  6 16:18:58 1994  Jason Molenda     (crash@sendai.cygnus.com)
-
-	* Makefile.in (install-info): add a semicolon in the if statement.
-
-Fri Apr 29 16:56:07 1994  David J. Mackenzie  (djm@rtl.cygnus.com)
-
-	* cfg-paper.texi: Update some outdated information.
-
-	* Makefile.in (install-info): Pass file, not directory, as last
-	arg to INSTALL_DATA.
-	(uninstall): New target.
-
-Thu Apr 28 14:42:22 1994  David J. Mackenzie  (djm@rtl.cygnus.com)
-
-	* configure.texi: Comment out @smallbook.
-
-	* Makefile.in: Define TEXI2DVI and TEXIDIR, and use the latter.
-	Remove info files in realclean, not clean, per coding standards.
-	Remove TeX output in clean.
-
-Tue Apr 26 17:18:03 1994  Jason Molenda (crash@sendai.cygnus.com)
-
-        * Install.in:  fixincludes output is actually put in fixincludes.log,
-        but echo'ed messages claim it is fixinc.log.  This is the same
-	messages as I logged in March 4 1994, but for some reason we found
-	the change hadn't been done.  I'll have to dig through the logs
-	and find out what I really did do that day. :)
-
-Mon Apr 25 20:28:19 1994  Jason Molenda   (crash@sendai.cygnus.com)
-
-	* Install.in:  use eval to call do_mt() for Ultrix brokenness.
-
-Mon Apr 25 20:00:00 1994  Jason Molenda   (crash@sendai.cygnus.com)
-
-	* Install.in(do_mt): exit with error status 1 if # of parameters
-	!= 3.
-
-Mon Apr 25 19:42:36 1994  Jason Molenda   (crash@sendai.cygnus.com)
-
-	* Install.in:  lose TAPE_FORWARD and TAPE_REWIND, add do_mt()
-	to do all tape movement operations.  Currently untested.  Addresses
-	PR # 4886 from bull.
-
-	* Install.in: add 1994 to the copyright thing.
-
-Fri Apr 22 19:05:13 1994  David J. Mackenzie  (djm@rtl.cygnus.com)
-
-	* standards.texi: Update from FSF.
-
-Fri Apr 22 15:46:10 1994  Jason Molenda (crash@cygnus.com)
-
-	* Install.in: Add $DDOPTS, has ``bs=124b'' for all systems except
-	AIX (some versions of AIX don't understand bs=124b.  Silly OS).
-
-Mon Apr  4 22:55:05 1994  Jason Molenda (crash@sendai.cygnus.com)
-
-	* Install.in: null out $TOOLS before adding stuff to it
-	non-destructively.
-
-Wed Mar 30 21:45:35 1994  David J. Mackenzie  (djm@rtl.cygnus.com)
-
-	* standards.texi: Fix typo.
-
-	* configure.texi, configure.man: Document --disable-.
-
-Mon Mar 28 13:22:15 1994  David J. Mackenzie  (djm@rtl.cygnus.com)
-
-	* standards.texi: Update from FSF.
-
-Sat Mar 26 09:21:44 1994  David J. Mackenzie  (djm@rtl.cygnus.com)
-
-	* standards.texi, make-stds.texi: Update from FSF.
-
-Fri Mar 25 22:59:45 1994  David J. Mackenzie  (djm@rtl.cygnus.com)
-
-	* configure.texi, configure.man: Document --enable-* options.
-
-Wed Mar 23 23:38:24 1994  Jason Molenda  (crash@sendai.cygnus.com)
-
-	* Install.in: set CPP to be gcc -E for fixincludes.
-
-Wed Mar 23 13:42:48 1994  Jason Molenda  (crash@sendai.cygnus.com)
-
-        * Install.in: set PATH to $PATH:/bin:/usr/bin so we can pick
-        up native tools even if the user doesn't have them in his
-        path.
-
-        * Install.in: ``hppa-1.1-hp-hpux'' -> ``hppa1.1-hp-hpux''.
-
-Tue Mar 15 22:09:20 1994  Jason Molenda  (crash@sendai.cygnus.com)
-        
-        * Install.in: TAPE_REWIND and TAPE_FORWARD variables for Unixunaware,
-        added switch statement to detect if system is Unixunaware.
-
-Fri Mar  4 12:10:30 1994  Jason Molenda (crash@sendai.cygnus.com)
-
-        * Install.in:  fixincludes output is actually put in fixincludes.log,
-        but echo'ed messages claim it is fixinc.log.
-
-Wed Nov  3 02:58:02 1993  Jeffrey Osier  (jeffrey@thepub.cygnus.com)
-
-	* subst-strings:  output TEXBUNDLE for more install notes matching
-	* install-texi.in:  PRMS info now exists
-
-Tue Oct 26 16:57:12 1993  K. Richard Pixley  (rich@sendai.cygnus.com)
-
-	* subst-strings: match solaris*.  Also, add default case to catch
-	  and error out for unrecognized systems.
-
-Thu Aug 19 18:21:31 1993  david d `zoo' zuhn  (zoo@rtl.cygnus.com)
-
-	* Install.in: handle the new fixproto work
-
-Mon Jul 19 12:05:41 1993  david d `zoo' zuhn  (zoo@cirdan.cygnus.com)
-
-	* Install.in: remove "MT=tctl" for AIX (not needed, and barely
-	worked anyway)
-
-Mon Jun 14 19:09:22 1993  Jeffrey Osier  (jeffrey@cygnus.com)
-
-	* subst-strings: changed HOST to recognize Solaris for install notes
-
-Thu Jun 10 16:01:25 1993  Jeffrey Osier  (jeffrey@cygnus.com)
-
-	* dos-inst.texi:  new file.
-
-Wed Jun  9 19:23:59 1993  Jeffrey Osier  (jeffrey@rtl.cygnus.com)
-
-        * install-texi.in:        added conditionals (nearly complete)
-                                  cleaned up
-                                  added support for other releases (not done)
-
-Wed Jun  9 15:53:58 1993  Jim Kingdon  (kingdon@cygnus.com)
-
-	* Makefile.in (install-info): Use INSTALL_DATA.
-	({dist,real}clean): Also delete Makefile and config.status.
-
-Fri Jun  4 17:09:56 1993  Jeffrey Osier  (jeffrey@cygnus.com)
-
-	* subst-strings:  added data for OS_STRING
-
-	* subst-strings:  added support for OS_STRING
-
-Thu Jun  3 00:37:01 1993  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* Install.in: pull COPYING and COPYING.LIB off of the tape 
-
-Tue Jun  1 16:52:08 1993  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* subst-strings: replace RELEASE_DIR too
-
-Mon Mar 22 23:55:27 1993  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* Makefile.in: add installcheck target
-
-Wed Mar 17 02:21:15 1993  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* Install.in: fix 'source only' extraction bug where it looked for
-	the src dir under H-<host>/src instead of src; also remove stray
-	reference to EMACSHIBIN
-
-Mon Mar 15 01:25:45 1993  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* make-stds.texi: added 'installcheck' to the standard targets
-
-Tue Mar  9 19:48:28 1993  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* standards.texi: added INFO-DIR-ENTRY, updated version from the FSF
-
-Tue Feb  9 12:40:23 1993  Ian Lance Taylor  (ian@cygnus.com)
-
-	* Makefile.in (standards.info): Added -I$(srcdir) to find
-	make-stds.texi.
-
-Mon Feb  1 16:32:56 1993  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* standards.texi: updated to latest FSF version, which includes:
-
-	* make-stds.texi: new file
-
-Mon Nov 30 01:31:40 1992  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* install-texi.in, relnotes.texi, intro.texi: changed Cygnus phone
-	numbers from the old Palo Alto ones to the new Mtn. View numbers
-
-Mon Nov 16 16:50:43 1992  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* Makefile.in: define $(RM) to "rm -f"
-
-Sun Oct 11 16:05:48 1992  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
-
-	* intro.texi: added INFO-DIR-ENTRY
-
diff --git a/gnu/usr.bin/binutils/etc/cfg-paper.info b/gnu/usr.bin/binutils/etc/cfg-paper.info
deleted file mode 100644
index 717ce559186..00000000000
--- a/gnu/usr.bin/binutils/etc/cfg-paper.info
+++ /dev/null
@@ -1,659 +0,0 @@
-This is Info file cfg-paper.info, produced by Makeinfo-1.55 from the
-input file ./cfg-paper.texi.
-
-   This document attempts to describe the general concepts behind
-configuration of the GNU Development Tools.  It also discusses common
-usage.
-
-   Copyright (C) 1991, 1992, 1994 Cygnus Support 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.
-
-START-INFO-DIR-ENTRY
-* configuration: (cfg-paper).	Some theory on configuring source.
-END-INFO-DIR-ENTRY
-
-
-File: cfg-paper.info,  Node: Top,  Next: Some Basic Terms,  Prev: (dir),  Up: (dir)
-
-   This document attempts to describe the general concepts behind
-configuration of the GNU Development Tools.  It also discusses common
-usage.
-
-* 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
-
-
-File: cfg-paper.info,  Node: Some Basic Terms,  Next: Specifics.,  Prev: Top,  Up: Top
-
-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.
-
-   *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.
-
-* Menu:
-
-* Host Environments::		Host Environments
-* Configuration Time Options::	Configuration Time Options
-
-
-File: cfg-paper.info,  Node: Host Environments,  Next: Configuration Time Options,  Prev: Some Basic Terms,  Up: Some Basic Terms
-
-Host Environments
-=================
-
-   In this document, the word *host* refers to the environment in which
-the source in question 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.  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 `bcopy' function and so it is emulated using the `memcpy' funtion.
-
-   Host environment simply refers to the environment in which the
-program will be built from the source.
-
-
-File: cfg-paper.info,  Node: Configuration Time Options,  Prev: Host Environments,  Up: Some Basic Terms
-
-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, to choose infix you
-might use:
-
-     ./configure sun3 --enable-notation=infix
-
-while for a sun4 with postfix you might use:
-
-     ./configure sun4 --enable-notation=postfix
-
-   If we wanted to build both at the same time, the intermediate pieces
-used in the build process must be kept separate.
-
-     mkdir ../objdir.sun4
-     (cd ../objdir.sun4 ; ../configure sun4 --enable-notation=postfix --srcdir=../src)
-     mkdir ../objdir.sun3
-     (cd ../objdir.sun3 ; ../configure sun3 --enable-notation=infix --srcdir=../src)
-
-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 `--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 `-' 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 `--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 `/usr/local'.  We refer to this location as `$(prefix)'.
-All user visible programs will be installed in ``$(prefix)'/bin'.  All
-other programs and files will be installed in a subdirectory of
-``$(prefix)'/lib'.
-
-   You can only change `$(prefix)' as a configuration time option.
-
-     ./configure sun4 --enable-notation=postfix --prefix=/local
-
-Will configure the source such that:
-
-     make install
-
-will put its programs in `/local/bin' and `/local/lib/gcc'.  If you
-change `$(prefix)' 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 example
-and move on to the application that resides in these directories,
-namely, the source to a development environment.
-
-
-File: cfg-paper.info,  Node: Specifics.,  Next: Building Development Environments,  Prev: Some Basic Terms,  Up: Top
-
-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 --prefix=/local
-     ./configure sun3 --prefix=/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.
-
-
-File: cfg-paper.info,  Node: Building Development Environments,  Next: A Walk Through,  Prev: Specifics.,  Up: Top
-
-Building Development Environments
-*********************************
-
-   The 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 *target*.
-That is, the word *target* refers to the development environment
-produced by compiling this source and installing the resulting programs.
-
-   For the 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 `$(prefix)'.
-
-     ./configure sun4 --prefix=/local --target=sun3
-     ./configure sun3 --prefix=/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.
-
-
-File: cfg-paper.info,  Node: A Walk Through,  Next: Final Notes,  Prev: Building Development Environments,  Up: Top
-
-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
-
-
-File: cfg-paper.info,  Node: Native Development Environments,  Next: Emulation Environments,  Prev: A Walk Through,  Up: 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 quite
-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 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
-release and let's call the new development environment *stage1*.
-
-   Why bother?  Well, most people find that the 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 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.  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
-`$(prefix)' if you specified an alternate when you configured.
-
-   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 three basic categories.
-
-
-File: cfg-paper.info,  Node: Emulation Environments,  Next: Simple Cross Environments,  Prev: Native Development Environments,  Up: A Walk Through
-
-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 concepts of operating system universes and hosted operating
-systems are two such development environments.
-
-
-File: cfg-paper.info,  Node: Simple Cross Environments,  Next: Crossing Into Targets,  Prev: Emulation Environments,  Up: A Walk Through
-
-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.
-
-
-File: cfg-paper.info,  Node: Crossing Into Targets,  Next: Canadian Cross,  Prev: Simple Cross Environments,  Up: A Walk Through
-
-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 a another 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 mistaken as 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.
-
-
-File: cfg-paper.info,  Node: Canadian Cross,  Prev: Crossing Into Targets,  Up: A Walk Through
-
-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 *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
-*Canadian cross*.  It's a three party cross, Canada has a three party
-system, hence Canadian Cross.
-
-
-File: cfg-paper.info,  Node: Final Notes,  Next: Index,  Prev: A Walk Through,  Up: Top
-
-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.
-
-* Menu:
-
-* Hacking Configurations::	Hacking Configurations
-
-
-File: cfg-paper.info,  Node: Hacking Configurations,  Prev: Final Notes,  Up: Final Notes
-
-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 `--srcdir'
-or not.  The host and target specific Makefile may or may not exist.
-
-   * 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/mh-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/mt-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
-     `./config.status' or re-configure.
-
-
-File: cfg-paper.info,  Node: Index,  Prev: Final Notes,  Up: Top
-
-Index
-*****
-
-* Menu:
-
-* Bootstrapping:                        Native Development Environments.
-* Building:                             Some Basic Terms.
-* Canadian Cross:                       Canadian Cross.
-* Compilation:                          Some Basic Terms.
-* Cross:                                Native Development Environments.
-* Crossing into:                        Crossing Into Targets.
-* Crossing to:                          Simple Cross Environments.
-* Emulation:                            Emulation Environments.
-* Foreign:                              Native Development Environments.
-* host:                                 Host Environments.
-* Machines:                             Some Basic Terms.
-* Native:                               Native Development Environments.
-* Programs:                             Some Basic Terms.
-* Simple cross:                         Simple Cross Environments.
-* Software emulation:                   Emulation Environments.
-* Software emulator:                    Emulation Environments.
-* Source:                               Some Basic Terms.
-* Stage1:                               Native Development Environments.
-* Stage2:                               Native Development Environments.
-* Stage3:                               Native Development Environments.
-* Target:                               Building Development Environments.
-* Three party cross:                    Canadian Cross.
-* Three stage boot:                     Native Development Environments.
-
-
-
-Tag Table:
-Node: Top1055
-Node: Some Basic Terms2009
-Node: Host Environments2951
-Node: Configuration Time Options5513
-Node: Specifics.8316
-Node: Building Development Environments8934
-Node: A Walk Through11554
-Node: Native Development Environments11972
-Node: Emulation Environments16221
-Node: Simple Cross Environments17579
-Node: Crossing Into Targets19188
-Node: Canadian Cross21381
-Node: Final Notes24208
-Node: Hacking Configurations25003
-Node: Index26418
-
-End Tag Table
diff --git a/gnu/usr.bin/binutils/etc/cfg-paper.texi b/gnu/usr.bin/binutils/etc/cfg-paper.texi
deleted file mode 100644
index bcfbb31e13f..00000000000
--- a/gnu/usr.bin/binutils/etc/cfg-paper.texi
+++ /dev/null
@@ -1,717 +0,0 @@
-\input texinfo
-@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 @sc{gnu} Development Tools.
-It also discusses common usage.
-
-Copyright (C) 1991, 1992, 1994 Cygnus Support
-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, 1994 Cygnus Support
-
-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 @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 --enable-notation=infix
-@end example
-
-@noindent
-while for a sun4 with postfix you might use:
-
-@example
-./configure sun4 --enable-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 --enable-notation=postfix --srcdir=../src)
-mkdir ../objdir.sun3
-(cd ../objdir.sun3 ; ../configure sun3 --enable-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{-} 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}.
-
-You can only change @code{$(prefix)} as a configuration time
-option.
-
-@example
-./configure sun4 --enable-notation=postfix --prefix=/local
-@end example
-
-@noindent
-Will configure the source such that:
-
-@example
-make install
-@end example
-
-@noindent
-will put its 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 @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 @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 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 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.  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.
-
-@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 a another 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:
diff --git a/gnu/usr.bin/binutils/etc/configure.man b/gnu/usr.bin/binutils/etc/configure.man
deleted file mode 100644
index a7699041a71..00000000000
--- a/gnu/usr.bin/binutils/etc/configure.man
+++ /dev/null
@@ -1,166 +0,0 @@
-.\" -*- nroff -*-
-.\" Copyright (c) 1991, 1992, 1996 Cygnus Support
-.\" written by K. Richard Pixley
-.TH configure 1 "29 March 1996" "cygnus support" "Cygnus Support"
-.de BP
-.sp
-.ti \-.2i
-\(**
-..
-
-.SH NAME
-configure \- prepare source code to be built
-
-.SH SYNOPSIS
-configure HOST [--target=TARGET] [--srcdir=DIR] [--rm]
-            [--site=SITE] [--prefix=DIR] [--exec_prefix=DIR]
-            [--program_prefix=DIR] [--tmpdir=DIR]
-            [--with-PACKAGE[=YES/NO]] [--without-PACKAGE]
-            [--enable-FEATURE[=YES/NO]] [--disable-FEATURE]
-            [--norecursion] [--nfp] [-s] [-v] [-V | --version] [--help]
-
-.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, recursing
-in subdirectories, and some other miscellaneous file editing.
-
-.SH OPTIONS
-.I configure
-accepts the following options:
-
-.TP
-.I \--target=TARGET
-Requests that the sources be configured to target the
-.I TARGET
-machine.  If no target is specified explicitly, the target is assumed
-to be the same as the host.
-
-.TP
-.I \--srcdir=DIR
-tells configure to find the source in 
-.I DIR.
-Object code is always built in the current directory,
-.I `.'.
-
-.TP
-.I \--rm
-asks configure to remove a configuration rather than create one.
-
-.TP
-.I \--site=SITE
-asks configure to use any site-specific Makefile fragments for
-.I SITE
-when building Makefiles.
-
-.TP
-.I \--prefix=DIR
-sets the location in which to install files to
-.I DIR.
-The default is "/usr/local".
-
-.TP
-.I \--exec_prefix=DIR
-sets the root directory for host-dependent files to
-.I DIR.
-The default location is the value of
-.I prefix.
-
-.TP
-.I \--program_prefix=DIR
-configures the source to install programs which have the same names as
-common Unix programs, such as "make", in
-.I DIR.
-Also applies to programs which might be used for cross-compilation.
-
-.TP
-.I \--tmpdir=DIR
-sets the directory in which configure creates temporary files to
-.I DIR.
-
-.TP
-.I \--with-PACKAGE[=YES/NO]
-sets a flag for the build to recognize that
-.I PACKAGE
-is explicitly present or not present.  If
-.I \=YES/NO
-is nonexistent, the default is
-.I YES.
-.I \--without-PACKAGE
-is equivalent to 
-.IR \--with-PACKAGE=no .
-
-.TP
-.I \--enable-FEATURE[=YES/NO]
-sets a flag for the build to recognize that
-.I FEATURE
-should be included or not included.  If
-.I \=YES/NO
-is nonexistent, the default is
-.I YES.
-.I \--disable-FEATURE
-is equivalent to
-.IR --enable-FEATURE=no .
-
-.TP
-.I \--norecursion
-asks that only the current directory be configured.  Normally
-.I configure
-recurs on subdirectories.
-
-.TP
-.I \-nfp
-Notifies
-.I configure
-that all of the specified hosts have
-.I no floating point
-units.
-
-.TP
-.I \-s
-used internally by configure to supress status messages on
-subdirectory recursions.  Override with
-.I \-v
-
-.TP
-.I \-v
-verbose output.  Asks that configure print status lines for each
-directory configured.  Normally, only the status lines for the current
-directory are printed.
-
-.TP
-.I \--version
-.I \-V
-prints
-.I configure
-version number.
-
-.TP
-.I \-help
-displays a brief usage summary.
-
-
-.SH FILES
-configure.in	for each directory's individual needs
-.br
-Makefile.in	Makefile template
-.br
-config.sub	for parsing configuration names
-.br
-config.guess	for guessing HOST when not specified
-.br
-config.status	non-recursively rebuilds current directory
-
-.SH FILES
-.ta \w'gmon.sum 'u
-a.out	the namelist and text space.
-.br
-gmon.out	dynamic call graph and profile.
-.br
-gmon.sum summarized dynamic call graph and profile.
-
-.SH "SEE ALSO"
-.RB "`\|" configure "\|'"
-entry in 
-.B
-info.
diff --git a/gnu/usr.bin/binutils/etc/configure.texi b/gnu/usr.bin/binutils/etc/configure.texi
deleted file mode 100644
index 445777491fb..00000000000
--- a/gnu/usr.bin/binutils/etc/configure.texi
+++ /dev/null
@@ -1,1830 +0,0 @@
-\input texinfo    @c -*-texinfo-*-
-@setfilename configure.info
-@settitle Cygnus configure
-
-@synindex ky cp
-
-@setchapternewpage odd
-
-@ifinfo
-@format
-START-INFO-DIR-ENTRY
-* configure: (configure).        Cygnus configure.
-END-INFO-DIR-ENTRY
-@end format
-@end ifinfo
-
-@ifinfo
-This document describes the Cygnus Support version of @code{configure}.
-
-Copyright (C) 1991, 1992, 1993 Cygnus Support
-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
-
-@c We should not distribute texinfo files with smallbook enabled.
-@c @smallbook
-@finalout
-@titlepage
-@title Cygnus configure
-@author K. Richard Pixley
-@author Cygnus Support
-@page
-@cindex copyleft
-
-@vskip 0pt plus 1filll
-Edited January, 1993, by Jeffrey Osier, Cygnus Support.
-
-Copyright @copyright{} 1991, 1992, 1993 Cygnus Support
-
-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
-
-@c ---------------------------------------------------------------------
-@ifinfo
-@node Top
-@top Cygnus configure
-
-This file documents the configuration system used and distributed by
-Cygnus Support.
-
-@menu
-* What configure does::    What configure does
-* Invoking configure::     Invoking configure---basic usage
-* Using configure::        More than you ever wanted to know
-* Porting::                How to use configure with new programs
-* Variables Index::
-* Concept Index::
-@end menu
-@end ifinfo
-
-@c ---------------------------------------------------------------------
-@node What configure does
-@chapter What @code{configure} does
-@cindex Introduction
-@cindex Overview
-@cindex What @code{configure} does
-@kindex Cygnus Support Developer's Kit
-
-This manual documents Cygnus @code{configure}, a program which helps to
-automate much of the setup activity associated with building large suites of
-programs, such the Cygnus Support Developer's Kit.  This manual is therefore
-geared toward readers who are likely to face the problem of configuring
-software in source form before compiling and installing it.  We assume you are
-an experienced programmer or system administrator.
-@ifinfo
-For further background on this topic, see @ref{Some Basic Terms, , Apologia
-Configure, cfg-paper, On Configuring Development Tools}, by K. Richard
-Pixley.
-@end ifinfo
-@iftex
-For further background on this topic, see @cite{On Configuring Development
-Tools} by K. Richard Pixley.
-@end iftex
-
-When @code{configure} runs, it does the following things:
-
-@table @emph
-@item @bullet{} creates build directories
-@vindex srcdir
-@cindex @code{srcdir}
-@cindex Build directories
-When you run @code{configure} with the @samp{--srcdir} option, it uses the
-current directory as the @dfn{build directory}, creating under it a directory
-tree that parallels the directory structure of the source directory.  If you
-don't specify a @samp{srcdir}, @code{configure} first assumes that the source
-code you wish to configure is in your current directory; if it finds no
-@file{configure.in} input file there, it searches in the directory
-@code{configure} itself lies in.  (For details, see @ref{Build directories, ,
-Build directories}.)
-
-@item @bullet{} generates @file{Makefile}
-@cindex @code{Makefile} generation
-A @file{Makefile} template from the source directory, usually called
-@file{Makefile.in}, is copied to an output file in the build directory which is
-most often named @file{Makefile}.  @code{configure} places definitions for a
-number of standard @file{Makefile} macros at the beginning of the output file.
-If @w{@samp{--prefix=@var{dir}}} or @w{@samp{--exec_prefix=@var{dir}}} are
-specified on the @code{configure} command line, corresponding @file{Makefile}
-variables are set accordingly.  If host, target, or site-specific
-@file{Makefile} fragments exist, these are inserted into the output file.  (For
-details, see @ref{Makefile generation, , @code{Makefile} generation}.)
-
-@item @bullet{} generates @file{.gdbinit}
-@cindex @code{.gdbinit}
-If the source directory contains a @file{.gdbinit} file and the build directory
-is not the same as the source directory, a @file{.gdbinit} file is created in
-the build directory.  This @file{.gdbinit} file contains commands which allow
-the source directory to be read when debugging with the @sc{gnu} debugger,
-@code{gdb}.  (@xref{Command Files, , Command Files, gdb, Debugging With GDB}.)
-
-@item @bullet{} makes symbolic links
-@cindex Symbolic links
-Most build directories require that some symbolic links with generic names are
-built pointing to specific files in the source directory.  If the system where
-@code{configure} runs cannot support symbolic links, hard links are used
-instead.  (For details, see @ref{configure.in, , The @code{configure.in} input
-file}.)
-
-@item @bullet{} generates @file{config.status}
-@cindex @code{config.status}
-@code{configure} creates a shell script named @file{config.status} in the build
-directory.  This shell script, when run from the build directory (usually from
-within a @file{Makefile}), will reconfigure the build directory (but not its
-subdirectories).  This is most often used to have a @file{Makefile} update
-itself automatically if a new source directory is available.
-
-@item @bullet{} calls itself recursively
-@cindex Recursion
-If the source directory has subdirectories that should also be configured,
-@code{configure} is called for each.  
-@end table
-
-@c ---------------------------------------------------------------------
-@node Invoking configure
-@chapter Invoking @code{configure}
-@cindex Invoking @code{configure}
-@cindex Usage
-
-Cygnus @code{configure} is a shell script which resides in a source tree.  The
-usual way to invoke @code{configure} is from the shell, as follows:
-
-@cindex Example session
-@example
-eg$ ./configure @var{hosttype}
-@end example
-
-@noindent
-This prepares the source in the current directory (@file{.}) to be
-compiled for a @var{hosttype} environment.  It assumes that you wish to
-build programs and files in the default @dfn{build directory} (also the
-current directory, @file{.}).  If you do not specify a value for
-@var{hosttype}, Cygnus @code{configure} will attempt to discover this
-information by itself (@pxref{config.guess, , Determining system
-information}).  For information on @var{hosttype} environments,
-@xref{Host, , Host}.
-
-All @sc{gnu} software is packaged with one or more @code{configure} script(s)
-(@pxref{Configuration, , How Configuration Should Work, standards, GNU Coding
-Standards}).  By using @code{configure} you prepare the source for your
-specific environment by selecting and using @file{Makefile} fragments and
-fragments of shell scripts, which are prepared in advance and stored with the
-source.
-
-@code{configure}'s command-line options also allow you to specify other aspects
-of the source configuration:
-
-@smallexample
-  configure @var{hosttype}  [--target=@var{target}] [--srcdir=@var{dir}] [--rm]
-            [--site=@var{site}] [--prefix=@var{dir}] [--exec-prefix=@var{dir}]
-            [--program-prefix=@var{string}] [--tmpdir=@var{dir}]
-            [--with-@var{package}[=@var{yes/no}]] [--without-@var{package}]
-            [--enable-@var{feature}[=@var{yes/no}]] [--disable-@var{feature}]
-            [--norecursion] [--nfp] [-s] [-v] [-V | --version] [--help]
-@end smallexample
-
-@table @code
-@item --target=@var{target}
-@cindex @code{--target}
-@cindex @code{target} option
-@vindex target
-Requests that the sources be configured to target the @var{target} machine.  If
-no target is specified explicitly, the target is assumed to be the same as the
-host (i.e., a @dfn{native} configuration).  @xref{Host, , Host}, and
-@ref{Target, , Target}, for
-discussions of each.
-
-@item --srcdir=@var{dir}
-@cindex @code{--srcdir}
-@cindex @code{srcdir} option
-@vindex srcdir
-Direct each generated @file{Makefile} to use the sources located in directory
-@var{dir}.  Use this option whenever you wish the object code to reside in a
-different place from the source code.  The @dfn{build directory} is always
-assumed to be the directory you call @code{configure} from.  See @ref{Build
-directories, , Build directories}, for an example.  If the source directory is
-not specified, @code{configure} assumes that the source is in your current
-directory.  If @code{configure} finds no @file{configure.in} there, it searches
-in the same directory that the @code{configure} script itself lies in.
-Pathnames specified (Values for @var{dir}) can be either absolute relative to
-the @emph{build} directory.
-
-@item --rm
-@cindex @code{--rm}
-@cindex @code{rm} option
-@vindex rm
-@emph{Remove} the configuration specified by @var{hosttype} and the other
-command-line options, rather than create it.
-
-@c FIXME: check @ref
-@quotation
-@emph{Note:} We recommend that you use @samp{make distclean} rather than
-use this option; see @ref{Invoking make,,Invoking @code{make},make,GNU
-Make}, for details on @samp{make distclean}.
-@end quotation
-
-@item --site=@var{site}
-@cindex @code{--site}
-@cindex @code{site} option
-@vindex site
-Generate the @file{Makefile} using site-specific @file{Makefile} fragments for
-@var{site}.  @xref{Makefile fragments, , Adding information about local
-conventions}.
-
-@item --prefix=@var{dir}
-@cindex @code{--prefix}
-@cindex @code{prefix} option
-@vindex prefix
-Configure the source to install programs and files under directory @var{dir}.
-
-This option sets the variable @samp{prefix}.  Each generated @file{Makefile}
-will have its @samp{prefix} variables set to this value.  (@xref{What configure
-really does, , What @code{configure} really does}.)
-
-@item --exec-prefix=@var{dir}
-@cindex @code{--exec-prefix}
-@cindex @code{exec-prefix} option
-@vindex exec-prefix
-Configure the source to install @dfn{host dependent} files in @var{dir}.
-
-This option sets the variable @samp{exec_prefix}.  Each generated
-@file{Makefile} will have its @samp{exec_prefix} variables set to this value.
-(@xref{What configure really does, , What @code{configure} really does}.)
-
-@item --program-prefix=@var{string}
-@cindex @code{--program-prefix}
-@cindex @code{program-prefix} option
-@vindex program-prefix
-Configure the source to install certain programs using @var{string} as a
-prefix.  This applies to programs which might be used for cross-compilation,
-such as the compiler and the binary utilities, and also to programs which have
-the same names as common Unix programs, such as @code{make}.
-
-This option sets the variable @samp{program_prefix}.  Each generated
-@file{Makefile} will have its @samp{program_prefix} variables set to this
-value.  (@xref{What configure really does, , What @code{configure} really
-does}.)
-
-@item --tmpdir=@var{tmpdir}
-@cindex @code{--tmpdir}
-@cindex @code{tmpdir} option
-@vindex tmpdir
-Use the directory @var{tmpdir} for @code{configure}'s temporary files.  The
-default is the value of the environment variable @w{@code{TMPDIR}}, or
-@file{/tmp} if the environment variable is not set.
-
-@item --with-@var{package}[=@var{yes/no}]
-@itemx --without-@var{package}
-@cindex @code{--with-@var{package}}
-@cindex @code{with-@var{package}} option
-@vindex with-@var{package}
-@cindex @code{--without-@var{package}}
-@cindex @code{without-@var{package}} option
-@vindex without-@var{package}
-Indicate that @var{package} is present, or not present, depending on
-@var{yes/no}.  If @var{yes/no} is nonexistent, its value is assumed to be
-@code{yes}.  @samp{--without-@var{package}} is equivalent to
-@samp{--with-@var{package}=no}.
-
-For example, if you wish to configure the program @code{gcc} for a Sun
-SPARCstation running SunOS 4.x, and you want @code{gcc} to use the
-@sc{gnu} linker @code{ld}, you can configure @code{gcc} using
-
-@cindex Example session
-@smallexample
-eg$ configure --with-gnu-ld sun4
-@end smallexample
-
-@noindent
-@xref{What configure really does, , What @code{configure} really does}, for
-details.  See the installation or release notes for your particular package for
-details on which other @var{package} options are recognized.
-@c FIXME - need to include info about --with-* in other dox!
-
-@item --enable-@var{feature}[=@var{yes/no}]
-@itemx --disable-@var{feature}
-@cindex @code{--enable-@var{feature}}
-@cindex @code{enable-@var{feature}} option
-@vindex enable-@var{feature}
-@cindex @code{--disable-@var{feature}}
-@cindex @code{disable-@var{feature}} option
-@vindex disable-@var{feature}
-Include @var{feature}, or not, depending on @var{yes/no}.  If @var{yes/no} is
-nonexistent, its value is assumed to be @code{yes}.
-@samp{--disable-@var{feature}} is equivalent to
-@samp{--enable-@var{feature}=no}.
-
-@noindent
-@xref{What configure really does, , What @code{configure} really does}, for
-details.  See the installation or release notes for your particular package for
-details on which other @var{feature} options are recognized.
-@c FIXME - need to include info about --enable-* in other dox!
-
-@item --norecursion
-@cindex @code{--norecursion}
-@cindex @code{norecursion} option
-@vindex norecursion
-Configure only this directory; ignore any subdirectories.  This is used by the
-executable shell script @file{config.status} to reconfigure only the current
-directory; it is most often used non-interactively, when @code{make} is
-invoked.  (@xref{config.status, , @code{config.status}}.)
-
-@item --nfp
-@cindex @code{--nfp}
-@cindex @code{nfp} option
-@vindex nfp
-Assume that the intended @var{hosttype} has no floating point unit.
-
-@item -s
-@cindex @code{-s}
-@cindex @code{s} option
-Suppress status output.  This option is used internally by
-@code{configure} when calling itself recursively in subdirectories.  You
-can override this option with the @code{--verbose} option.
-
-@item -v
-@itemx --verbose
-@cindex @code{-v}
-@cindex @code{--verbose}
-@cindex @code{v} option
-@cindex @code{verbose} option
-@cindex Verbose Output
-@vindex verbose
-Print status lines for each directory configured.  Normally, only the
-status lines for the initial working directory are printed.
-
-@item --version
-@itemx -V
-@cindex version
-@cindex @code{--version}
-@cindex version
-Print the @code{configure} version number.
-
-@item --help
-@cindex Usage
-@cindex @code{--help}
-@cindex @code{help} option
-Print a short summary of how to invoke @code{configure}.
-@end table
-
-@cindex Abbreviating option names
-@cindex Truncating option names
-@cartouche
-@emph{Note:} You may introduce options with a single dash, @samp{-}, rather
-than two dashes, @samp{--}.  However, you may not be able to truncate long
-option names when using a single dash.  When using two dashes, options may be
-abbreviated as long as each option can be uniquely identified.  For example,
-@smallexample
-eg$ configure --s=/u/me/src @var{hosttype}
-@end smallexample
-@noindent
-is ambiguous, as @w{@samp{--s}} could refer to either @w{@samp{--site}} or
-@w{@samp{--srcdir}}.  However,
-@smallexample
-eg$ configure --src=/u/me/src @var{hosttype}
-@end smallexample
-@noindent
-is a valid abbreviation.
-@end cartouche
-
-
-@c ========================================================================
-@node Using configure
-@chapter Using @code{configure}
-@cindex Using @code{configure}
-@cindex Detailed usage
-@cindex Usage: detailed
-
-@code{configure} prepares source directories for building programs in
-them.  ``Configuring'' is the process of preparing software to compile
-correctly on a given @dfn{host}, for a given @dfn{target}.
-
-@code{configure} subsequently writes a configured @file{Makefile} from a
-pre-built template; @code{configure} uses variables that have been set in the
-configuring process to determine the values of some variables in the
-@file{Makefile}.  Because of this we will refer to both @code{configure}
-variables and @file{Makefile} variables.  This convention allows us to
-determine where the variable should be set initially, in either
-@file{configure.in} or @file{Makefile.in}.
-
-@menu
-* What configure really does:: What configure really does
-* configure.in::               The configure.in input file
-* Install locations::          Where to install things once they are built
-* Host::                       Telling configure what will source will be built
-* Target::                     Telling configure what the source will target
-* Makefile fragments::         Adding information about local conventions
-* Makefile extensions::        Extensions to the GNU coding standards
-@end menu
-
-@c ---------------------------------------------------------------------
-@node What configure really does
-@section What @code{configure} really does
-@cindex What @code{configure} really does
-@cindex Behind the scenes
-@cindex @code{configure} back end
-@cindex @code{configure} details
-
-Cygnus @code{configure} is a shell script that sets up an environment in
-which your programs will compile correctly for your machine and
-operating system, and will install in proper places.  @code{configure}
-accomplishes this task by doing the following:
-
-@itemize @bullet
-@item 
-it generates a @file{Makefile} from a custom template called
-@file{Makefile.in} in each relevant source directory;
-
-@item 
-it customizes the build process to your specifications; you set certain
-variables for @code{configure}, either on the command line or in the
-file @file{configure.in}, which subsequently sets variables in each
-generated @file{Makefile} to be used by @code{make} when actually
-building the software;
-
-@item 
-it creates @dfn{build directories}, places for your code to be compiled
-in before being installed;
-
-@item 
-it generates a @file{.gdbinit} in the build directory, if needed, to
-communicate to @code{gdb} where to find the program's source code;
-
-@item 
-it generates a shell script called @file{config.status}
-which is used most often by the @file{Makefile} to reconfigure itself;
-
-@item 
-it recurses in subdirectories, setting up entire trees so that they build
-correctly; if @code{configure} finds another @code{configure} script
-further down in a given source tree, it knows to use this script and not
-recur.
-@end itemize
-
-For the sake of safety (i.e., in order to prevent broken installations), the
-@sc{gnu} coding standards call for software to be @dfn{configured} in such a
-way that an end user trying to build a given package will be able to do so by
-affecting a finite number of variables.  All @sc{gnu} software comes with an
-executable @code{configure} shell script which sets up an environment within a
-build directory which will correctly compile your new package for your host
-(or, alternatively, whatever host you specify to @code{configure}).
-@ifinfo
-For further background on this topic, see @ref{Some Basic Terms, , Apologia
-Configure, cfg-paper, On Configuring Development Tools}, by K. Richard
-Pixley.
-@end ifinfo
-@iftex
-For further background on this topic, see @cite{On Configuring Development
-Tools} by K. Richard Pixley.
-@end iftex
-
-Use @code{configure} to set for the build process:
-
-@itemize @bullet
-@item 
-correct values for certain variables;
-
-@item 
-which type of host you wish to configure a given package for
-(@pxref{Host, , Host});
-
-@item 
-where you want to install this package (by using @samp{prefix},
-@samp{exec-prefix} and @samp{program-prefix}; @pxref{Install details, ,
-Full descriptions of all installation directories});
-
-@item 
-optionally, which type of machine you wish to @dfn{target} this
-package's output to (@pxref{Target, , Target});
-
-@item 
-which other @sc{gnu} packages are already installed and available to
-this particular build (by using the @samp{--with-@var{package}} option;
-@pxref{Invoking configure, , Invoking @code{configure}});
-
-@item 
-where to place temporary files (by using the @samp{--tmpdir=@var{dir}}
-option; @pxref{Invoking configure, , Invoking @code{configure}});
-
-@item whether to recur in subdirectories (changeable through the
-@w{@samp{--norecursion}} option; @pxref{Invoking configure, , Invoking
-@code{configure}}).
-@end itemize
-
-@code{configure} uses a few other files to complete its tasks.  These are
-discussed in detail where noted.
-
-@table @code
-@cindex Other files
-@item configure.in
-@cindex @code{configure.in} definition
-Input file for @code{configure}.  Shell script fragments reside here.
-@xref{configure.in, , The @code{configure.in} input file}.
-
-@item Makefile.in
-@cindex @code{Makefile.in} definition
-Template which @code{configure} uses to build a file called @file{Makefile} in
-the @dfn{build directory}.  @xref{Makefile generation, , @code{Makefile}
-generation}.
-
-@item config.sub
-@cindex @code{config.sub} definition
-Shell script used by @code{configure} to expand referents to the
-@var{hosttype} argument into a single specification of the form
-@w{@var{cpu-vendor-os}}.  For instance, on the command line you can
-specify
-
-@cindex Example session
-@example
-eg$ ./configure sun4
-@end example
-
-@noindent
-to configure for a Sun SPARCstation running SunOS 4.x.  @code{configure}
-consults @code{config.sub} to find that the three-part specification for this
-is
-
-@example
-sparc-sun-sunos4.1.1
-@end example
-
-@noindent
-which notes the @var{cpu} as @samp{sparc}, the @var{manufacturer} as @samp{sun}
-(Sun Microsystems), and the @var{os} (operating system) as @samp{sunos4.1.1},
-the SunOS 4.1.1 release.  @xref{configure variables, , Variables available to @code{configure}}.
-
-@item config.guess
-@cindex @code{config.guess} definition
-If you do not put the @var{hosttype} argument on the command line,
-@code{configure} uses the @code{config.guess} shell script to make an
-analysis of your machine (it assumes that you wish to configure your
-software for the type of machine on which you are running).  The output
-of @code{config.guess} is a three-part identifier as described above.
-
-@item config.status
-@cindex @code{config.status} definition
-The final step in configuring a directory is to create a shell script,
-@code{config.status}.  The main purpose of this file is to allow the
-@file{Makefile} for the current directory to rebuild itself, if
-necessary.  @xref{config.status, , @code{config.status}}.
-
-@item config/*
-@cindex @code{config/} subdirectory
-@code{configure} uses three types of @file{Makefile} @dfn{fragments}, which
-reside in the directory @file{@var{srcdir}/config/}.  @xref{Makefile fragments,
-, Adding information about local conventions}.
-@end table
-
-@menu
-* Build variables::         Variable-spaghetti made simple 
-* Build directories::       Build directories described well
-* Makefile generation::     To build a Makefile
-* config.guess::            Be vewwy quiet, I'm hunting system information
-* config.status::           To rebuild a Makefile
-@end menu
-
-@c ---------------------------------------------------------------------
-@node Build variables
-@subsection Build variables
-@cindex Build variables
-@cindex Cygnus Support Developer's Kit
-@cindex Variables
-
-There are several variables in the build process which you can control through
-build programs such as @code{make}.  These include machine definitions, local
-conventions, installation locations, locations for temporary files, etc.  This
-data is accessible through certain variables which are configurable in the
-build process; we refer to them as @dfn{build variables}.
-
-For lists of build variables which you can affect by using @code{configure},
-see @ref{configure variables, , Variables available to @code{configure.in}},
-and @ref{Install details, , Full descriptions of all installation directories}.
-
-Generally, build variables, which are used by the @file{Makefile} to
-determine various aspects of the build and installation processes, are
-changeable with command-line options to @code{configure}.  In most large
-suites of programs, like the Cygnus Support Developer's Kit, the
-individual programs reside in several subdirectories of a single source
-code ``tree''.  All of these subdirectories need to be configured with
-information relative to the @dfn{build directory}, which is not known
-until @code{configure} is run.  Unless specified otherwise,
-@code{configure} recursively configures every subdirectory in the source
-tree.
-
-Build variables are passed from @code{configure} directly into the
-@file{Makefile}, and use the same names (except that dashes are
-transformed into underbars; for example, when you specify the option
-@samp{--exec-prefix} on the command line, the @file{Makefile} variable
-@samp{exec_prefix} is set).  In other words, if you specify
-
-@cindex Example session
-@example
-eg$ ./configure --prefix=/usr/gnu/local @dots{} @var{hosttype}
-@end example
-
-@noindent
-on the command line, @code{configure} sets an variable called @samp{prefix} to
-@samp{/usr/gnu/local}, and passes this into the @file{Makefile} in the same
-manner.  After this command, each @file{Makefile} generated by @code{configure}
-will contain a line that reads:
-
-@example
-prefix = /usr/gnu/local
-@end example
-
-For a list of the @file{Makefile} variables @code{configure} can change, and
-instructions on how to change them, see @ref{configure variables, , Variables
-available to @code{configure.in}}, and @ref{Invoking configure, , Invoking
-@code{configure}}.
-
-@c ---------------------------------------------------------------------
-@node Build directories
-@subsection Build directories
-@cindex Build directories
-@cindex Object directories
-@cindex Building for multiple hosts
-@cindex Building for multiple targets
-
-By default, @code{configure} builds a @file{Makefile} and symbolic links in the
-same directory as the source files.  This default works for many cases, but it
-has limitations.  For instance, using this approach, you can only build object
-code for one host at a time.
-
-We refer to each directory where @code{configure} builds a @file{Makefile} as
-a @dfn{build directory}.
-
-The build directory for any given build is always the directory from which you
-call @code{configure}, or @file{.} relative to your prompt.  The default
-@dfn{source directory}, the place @code{configure} looks to find source code,
-is also @file{.}.  For instance, if we have a directory @file{/gnu-stuff/src/}
-that is the top branch of a tree of @sc{gnu} source code we wish to configure,
-then the program we will use to configure this code is
-@file{/gnu-stuff/src/configure}, as follows.  (Assume for the sake of argument
-that our machine is a sun4.)
-
-@cindex Example session
-@smallexample
-@group
-eg$ cd /gnu-stuff/src
-eg$ ./configure sun4
-Created "Makefile" in /gnu-stuff/src
-eg$
-@end group
-@end smallexample
-
-We just configured the code in @file{/gnu-stuff/src} to run on a Sun
-SPARCstation using SunOS 4.x by creating a @file{Makefile} in
-@file{/gnu-stuff/src}.  By default, we also specified that when this code is
-built, the object code should reside in the same directory,
-@file{/gnu-stuff/src}.
-
-However, if we wanted to build this code for more than one host, we would be in
-trouble, because the new configuration would write over the old one, destroying
-it in the process.  What we can do is to make a new @dfn{build directory} and
-configure from there.  Running @code{configure} from the new directory will
-place a correct @file{Makefile} and a @file{config.status} in this new file.
-That is all @code{configure} does; we must run @code{make} to generate any
-object code.  
-
-The new @file{Makefile} in @file{/gnu-stuff/sun4-obj}, created from the
-template file @file{/gnu-stuff/src/Makefile.in}, contains all the information
-needed to build the program.
-
-@cindex Example session
-@smallexample
-@group
-eg$ mkdir /gnu-stuff/sun4-obj
-eg$ cd /gnu-stuff/sun4-obj
-eg$ ../src/configure --srcdir=../src sun4
-Created "Makefile" in /gnu-stuff/sun4-obj
-eg$ ls
-Makefile       config.status
-eg$ make all info install install-info clean
-@var{compilation messages@dots{}}
-eg$ mkdir /gnu-stuff/solaris2
-eg$ cd /gnu-stuff/solaris2
-eg$ ../src/configure --srcdir=../src sol2
-Created "Makefile" in /gnu-stuff/solaris2
-eg$ ls
-Makefile       config.status
-eg$ make all info install install-info clean
-@var{compilation messages@dots{}}
-@end group
-@end smallexample
-
-We can repeat this for other configurations of the same software simply
-by making a new build directory and reconfiguring from inside it.  If
-you do not specify the @var{hosttype} argument, @code{configure}
-will attempt to figure out what kind of machine and operating system you
-happen to be using.  @xref{config.guess, , Determining system
-information}.  Of course, this may not always be the configuration you
-wish to build.
-
-@emph{Caution:} If you build more than one configuration for a single program,
-remember that you must also specify a different @samp{--prefix} for each
-configuration at configure-time.  Otherwise, both configurations will be
-installed in the same default location (@file{/usr/local}); the configuration
-to be installed last would overwrite previously installed configurations.
-
-@c ---------------------------------------------------------------------
-@node Makefile generation
-@subsection @code{Makefile} generation
-@cindex @code{Makefile} generation
-
-Cygnus @code{configure} creates a file called @file{Makefile} in the build
-directory which can be used with @code{make} to automatically build a given
-program or package.  @code{configure} also builds a @file{Makefile} for each
-relevant subdirectory for a given program or package (irrelevant subdirectories
-would be those which contain no code which needs configuring, and which
-therefore have no @code{configure} input file @file{configure.in} and no
-@file{Makefile} template @file{Makefile.in}).  @xref{Running, @code{make}
-Invocation, How to Run @code{make}, make, GNU Make}, for details on using
-@code{make} to compile your source code.
-
-Each @file{Makefile} contains variables which have been configured for a
-specific build.  These build variables are determined when @code{configure} is
-run.  All build variables have defaults.  By default, @code{configure}
-generates a @file{Makefile} which specifies: 
-
-@cindex Default configuration
-@itemize @bullet
-@item a @dfn{native} build, which is to occur 
-
-@item in the current directory, and which will be installed 
-
-@item in the default installation directory (@file{/usr/local}) when the code
-is compiled with @code{make}.  
-@end itemize
-
-@noindent
-Variables are changeable through command-line options to @code{configure}
-(@pxref{Invoking configure, , Invoking @code{configure}}).
-
-If you are porting a new program and intend to use @code{configure}, see
-@ref{Porting, , Porting with @code{configure}}, as well as @ref{Makefiles, ,
-Writing Makefiles, make, GNU Make}, and @ref{Makefiles, , Makefile Conventions,
-standards, GNU Coding Standards}.
-
-@c ---------------------------------------------------------------------
-@node config.guess
-@subsection Determining system information
-@cindex @code{config.guess}
-
-The shell script @code{config.guess} is called when you do not specify a
-@var{hosttype} on the command line to @code{configure}.  @code{config.guess}
-acquires available system information from your local machine through the shell
-command @code{uname}.  It compares this information to a database and attempts
-to determine a usable three-part system identifier (known as a @dfn{triple}) to
-use as your @var{hosttype}.  @xref{What configure really does, , What
-@code{configure} really does}, to see how this information is used.
-
-@emph{Note:}  If you do not specify a @var{hosttype} on the command line,
-@code{configure} will attempt to configure your software to run on the machine
-you happen to be using.  This may not be the configuration you desire.
-
-@c ---------------------------------------------------------------------
-@node config.status
-@subsection @code{config.status}
-@cindex @code{config.status}
-
-The final step in configuring a directory is to create an executable shell
-script, @file{config.status}.  The main purpose of this file is to allow the
-@file{Makefile} for the current directory to rebuild itself, if necessary.  It
-is usually run from within the @file{Makefile}.  @xref{Makefile extensions, ,
-Extensions to the @sc{gnu} coding standards}.
-
-@file{config.status} also contains a record of the @code{configure} session
-which created it.  
-
-@c ---------------------------------------------------------------------
-@node configure.in
-@section The @code{configure.in} input file
-@cindex @code{configure.in}
-
-A @file{configure.in} file for Cygnus @code{configure} consists of a
-@dfn{per-invocation} section, followed by a @dfn{per-host} section, followed by
-a @dfn{per-target} section, optionally followed by a @dfn{post-target} section.
-Each section is a shell script fragment, which is executed by the
-@code{configure} shell script at an appropriate time.  Values are passed among
-@code{configure} and the shell fragments through a set of shell variables.
-When each section is being interpreted by the shell, the shell's current
-directory is the build directory, and any files created by the section (or
-referred to by the section) will be relative to the build directory.  To
-reference files in other places (such as the source directory), prepend a shell
-variable such as @samp{$(srcdir)/} to the desired file name.
-
-@cindex @i{per-invocation} section
-The beginning of the @file{configure.in} file begins the @dfn{per-invocation}
-section.
-
-@cindex @i{per-host} section
-A line beginning with @samp{# per-host:} begins the @dfn{per-host} section.
-
-@cindex @i{per-target} section
-A line beginning with @samp{# per-target:} begins the @dfn{per-target} section.
-
-@cindex @i{post-target} section
-If it exists, the @dfn{post-target} section begins with @samp{# post-target:}.
-
-@menu
-* configure variables::    Variables available to configure.in
-* Minimal::                A minimal configure.in
-* Declarations::           For each invocation
-* per-host::               Host-specific instructions
-* per-target::             Target-specific instructions
-* post-target::            Instructions to be executed after target info
-* Example::                An example configure.in
-@end menu
-
-@c ---------------------------------------------------------------------
-@node configure variables
-@subsection Variables available to @code{configure.in}
-@cindex @file{configure.in} interface
-@cindex configure variables
-
-The following variables pass information between the standard parts of
-@code{configure} and the shell-script fragments in @file{configure.in}:
-
-@table @code
-@item srctrigger
-@cindex @code{srctrigger}
-@vindex srctrigger
-Contains the name of a source file that is expected to live in the source
-directory.  You must usually set this in the @dfn{per-invocation} section of
-@file{configure.in}.  @code{configure} tests to see that this file exists.  If
-the file does not exist, @code{configure} prints an error message.  This is
-used as a sanity check that @file{configure.in} matches the source directory.
-
-@item srcname
-@cindex @code{srcname}
-@vindex srcname
-Contains the name of the source collection contained in the source directory.
-You must usually set this in the @dfn{per-invocation} section of
-@file{configure.in}.  If the file named in @samp{srctrigger} does not exist,
-@code{configure} uses the value of @samp{srcname} when it prints the error
-message.
-
-@item configdirs
-@cindex @code{configdirs}
-@vindex configdirs
-Contains the names of any subdirectories in which @code{configure} should
-recurse.  You must usually set this in the @dfn{per-invocation} section of
-@file{configure.in}.
-If @file{Makefile.in} contains a line starting with @samp{SUBDIRS =},
-then it will be replaced with an assignment to @samp{SUBDIRS} using
-the value of @samp{configdirs} (if @samp{subdirs} is empty).  This can
-be used to determine which directories to configure and build depending
-on the host and target configurations.
-@c Most other matching makefile/config vars use the same name.  Why not
-@c this? (FIXME).
-@c Can we get rid of SUBDIRS-substitution?  It doesn't work well with subdirs.
-Use @samp{configdirs} (instead of the @samp{subdirs} variable
-described below) if you want to be able to partition the
-subdirectories, or use independent @file{Makefile} fragments.
-Each subdirectory can be independent, and independently reconfigured.
-
-@item subdirs
-@cindex @code{subdirs}
-@vindex subdirs
-Contains the names of any subdirectories where @code{configure} should create a
-@file{Makefile} (in addition to the current directory), @emph{without}
-recursively running @code{configure}.  Use @samp{subdirs} (instead of the
-@samp{configdirs} variable described above) if you want to configure all of the
-directories as a unit.  Since there is a single invocation of @code{configure}
-that configures many directories, all the directories can use the same
-@file{Makefile} fragments, and the same @code{configure.in}.
-
-@item host
-@cindex @code{host}
-@cindex Canonical ``triple''
-@vindex host
-Contains the full configuration name for the host (generated by the script
-@file{config.sub} from the name that you entered).  This is a three-part
-name (commonly referred to as a @dfn{triple}) of the form
-@var{cpu}-@var{vendor}-@var{os}.
-
-There are separate variables @samp{host_cpu}, @samp{host_vendor}, and
-@samp{host_os} that you can use to test each of the three parts; this variable
-is useful, however, for error messages, and for testing combinations of the
-three components.
-
-@item host_cpu
-@vindex host_cpu
-Contains the first element of the canonical triple representing the host
-as returned by @file{config.sub}.  This is occasionally used to
-distinguish between minor variations of a particular vendor's operating
-system and sometimes to determine variations in binary format between
-the host and the target.
-
-@item host_vendor
-@vindex host_vendor
-Contains the second element of the canonical triple representing the host as
-returned by @file{config.sub}.  This is usually used to distinguish among the
-numerous variations of @emph{common} operating systems.
-@c "@emph{common} OS" doesn't convey much to me.  Is this meant to cover 
-@c cases like Unix, widespread but with many variations?
-
-@item host_os
-@vindex host_os
-Contains the the third element of the canonical triple representing the
-host as returned by @file{config.sub}.
-
-@item target
-@cindex @code{target}
-@cindex Canonical ``triple''
-@vindex target
-Contains the full configuration name (generated by the script @file{config.sub}
-from the name that you entered) for the target.  Like the host, this is a
-three-part name of the form @var{cpu}-@var{vendor}-@var{os}.
-
-There are separate variables @samp{target_cpu}, @samp{target_vendor}, and
-@samp{target_os} that you can use to test each of the three parts; this
-variable is useful, however, for error messages, and for testing combinations
-of the three components.
-
-@item target_cpu
-@vindex target_cpu
-Contains the first element of the canonical triple representing the target as
-returned by @file{config.sub}.  This variable is used heavily by programs which
-are involved in building other programs, like the compiler, assembler, linker,
-etc.  Most programs will not need the @samp{target} variables at all, but this
-one could conceivably be used to build a program, for instance, that operated
-on binary data files whose byte order or alignment differ from the system where
-the program is running.
-
-@item target_vendor
-@vindex target_vendor
-Contains the second element of the canonical triple representing the target as
-returned by @file{config.sub}.  This is usually used to distinguish among the
-numerous variations of @emph{common} operating systems or object file
-formats.  It is sometimes used to switch between different flavors of user
-interfaces.
-@c above query re "@emph{common} OS" applies here too
-
-@item target_os
-@vindex target_os
-Contains the the third element of the canonical triple representing the
-target as returned by @file{config.sub}.  This variable is used by
-development tools to distinguish between subtle variations in object
-file formats that some vendors use across operating system releases.  It
-might also be use to decide which libraries to build or what user
-interface the tool should provide.
-
-@item floating_point
-@cindex @code{floating_point}
-@cindex @code{nfp} option
-@vindex floating_point
-Set to @samp{no} if you invoked @code{configure} with the @samp{--nfp}
-command-line option, otherwise it is empty.  This is a request to target
-machines with @dfn{no floating point} unit, even if the targets ordinarily have
-floating point units available.
-
-@item gas
-@cindex @code{with-gnu-as} option
-@vindex gas
-Set to @samp{true} if you invoked @code{configure} with the
-@w{@samp{--with-gnu-as}} command line option, otherwise it is empty.  This is a
-request to assume that the specified @var{hosttype} machine has @sc{gnu} @code{as}
-available even if it ordinarily does not.
-
-@item srcdir
-@cindex @code{srcdir}
-@vindex srcdir
-Set to the name of the directory containing the source for this program.
-This will be different from @file{.} if you have specified the
-@samp{--srcdir=@var{dir}} option.  @samp{srcdir} can indicate either an
-absolute path or a path relative to the build directory.
-
-@item package_makefile_frag
-@vindex package_makefile_frag
-If set in @file{configure.in}, this variable should be the name a file relative
-to @samp{srcdir} to be included in the resulting @file{Makefile}.  If the named
-file does not exist, @code{configure} will print a warning message.  This
-variable is not set by @code{configure}.
-
-@item host_makefile_frag
-@vindex host_makefile_frag
-If set in @file{configure.in}, this variable should be the name a file relative
-to @samp{srcdir} to be included in the resulting @file{Makefile}.  If the named
-file does not exist, @code{configure} will print a warning message.  This
-variable is not set by @code{configure}.
-
-@item target_makefile_frag
-@vindex target_makefile_frag
-If set in @file{configure.in}, this variable should be the name of a file,
-relative to @samp{srcdir}, to be included in the resulting @file{Makefile}.  If
-the named file does not exist, @code{configure} will print a warning message.
-This variable is not set by @code{configure}.
-
-@item site_makefile_frag
-@vindex site_makefile_frag
-Set to a file name representing to the default @file{Makefile} fragment for
-this host.  It may be set in @file{configure.in} to override this default.
-Normally @samp{site_makefile_frag} is empty, but will have a value if you
-specify @samp{--site=@var{site}} on the command line.
-@ignore -- this doesn't fit
-It is probably not a good idea to override this variable from
-@file{configure.in}, since that may defeat the @code{configure} user's
-intentions.
-@end ignore
-
-@item Makefile
-@vindex Makefile
-Set to the name of the generated @file{Makefile}.  Normally this value is
-precisely @file{Makefile}, but some programs may want something else.
-
-@item removing
-@cindex @code{rm} option
-@vindex removing
-Normally empty but will be set to some non-null value if you specified
-@samp{--rm} on the command line.  That is, if @samp{removing} is not empty,
-then @code{configure} is @emph{removing} a configuration rather than creating
-one.
-
-@item files
-@cindex Symbolic links
-@vindex files
-If this variable is not empty following the @dfn{per-target} section,
-then each word in its value will be the target of a symbolic link named
-in the corresponding word from the @samp{links} variable.
-
-@item links
-@cindex Symbolic links
-@vindex links
-If the @samp{files} variable is not empty following the @dfn{per-target}
-section, then @code{configure} creates symbolic links with the first word of
-@samp{links} pointing to the first word of @samp{files}, the second word of
-@samp{links} pointing to the second word of @samp{files}, and so on.
-@end table
-
-@c ---------------------------------------------------------------------
-@node Minimal
-@subsection A minimal @code{configure.in}
-@cindex Minimal @file{configure.in} example
-
-A minimal @file{configure.in} consists of four lines.
-
-@example
-srctrigger=foo.c
-srcname="source for the foo program"
-# per-host:
-# per-target:
-@end example
-
-The @samp{# per-host:} and @samp{# per-target:} lines divide the file into the
-three required sections.  The @samp{srctrigger} line names a file.
-@code{configure} checks to see that this file exists in the source directory
-before configuring.  If the @samp{srctrigger} file does not exist,
-@code{configure} uses the value of @samp{srcname} to print an error message
-about not finding the source.
-
-This particular example uses no links, and only the default host,
-target, and site-specific @file{Makefile} fragments if they exist.
-
-@c ---------------------------------------------------------------------
-@node Declarations
-@subsection For each invocation
-@cindex For each invocation
-@cindex Declarations section
-@cindex @i{per-invocation} section
-
-@code{configure} invokes the entire shell script fragment from the start of
-@file{configure.in} up to a line beginning with @w{@samp{# per-host:}}
-immediately after parsing command line arguments.  The variables
-@samp{srctrigger} and @samp{srcname} @emph{must} be set here.
-
-You might also want to set the variables @samp{configdirs} and
-@samp{package_makefile_frag} here.
-
-@c ---------------------------------------------------------------------
-@node per-host
-@subsection Host-specific instructions
-@cindex Host-specific instructions
-@cindex @i{host} shell-script fragment
-@cindex @i{per-host} section
-
-The @dfn{per-host} section of @file{configure.in} starts with the line that
-begins with @w{@samp{# per-host:}} and ends before a line beginning with
-@w{@samp{# per-target:}}.  @code{configure} invokes the commands in the
-@dfn{per-host} section when determining host-specific information.
-
-This section usually contains a big @code{case} statement using the variable
-@samp{host} to determine appropriate values for @samp{host_makefile_frag} and
-@samp{files}, although @samp{files} is not usually set here.  Usually, it is
-set at the end of the @dfn{per-target} section after determining the names of
-the target specific configuration files.
-
-@c ---------------------------------------------------------------------
-@node per-target
-@subsection Target-specific instructions
-@cindex Target-specific instructions
-@cindex target shell-script fragment
-@cindex @i{per-target} section
-
-The @dfn{per-target} section of @file{configure.in} starts with the line that
-begins with @w{@samp{# per-target:}} and ends before the line that begins with
-@w{@samp{# post-target:}}, if there is such a line.  Otherwise the
-@dfn{per-target} section extends to the end of the file.  @code{configure}
-invokes the commands in the @dfn{per-target} section when determining
-target-specific information, and before building any files, directories, or
-links.
-
-This section usually contains a big @code{case} statement using the variable
-@samp{target} to determine appropriate values for @samp{target_makefile_frag}
-and @samp{files}.  The last lines in the @dfn{per-target} section normally set
-the variables @samp{files} and @samp{links}.
-
-@c ---------------------------------------------------------------------
-@node post-target
-@subsection Instructions to be executed after target info
-@cindex Post-target shell-script fragment
-@cindex @i{post-target} section
-
-The @dfn{post-target} section is optional.  If it exists, the
-@samp{post-target} section starts with a line beginning with @w{@samp{#
-Post-target:}} and extends to the end of the file.  If it exists,
-@code{configure} invokes this section once for each target after
-building all files, directories, or links.
-
-This section is seldom needed, but you can use it to edit the @file{Makefile}
-generated by @code{configure}.
-
-@c ---------------------------------------------------------------------
-@node Example
-@subsection An example @code{configure.in}
-@cindex Example @file{configure.in}
-@cindex Sample @file{configure.in}
-@c @cindex @code{bison} @file{configure.in}
-@c this won't be the bison configure.in for long.. need better example
-
-Here is a small example of a @file{configure.in} file.
-
-@cartouche
-@example
-@group
-# This file is a collection of shell script fragments
-# used to tailor a template configure script as
-# appropriate for this directory.  For more information,
-# see configure.texi.
-
-configdirs=
-srctrigger=warshall.c
-srcname="bison"
-
-# per-host:
-case "$@{host@}" in
-m88k-motorola-*)
-        host_makefile_frag=config/mh-delta88
-        ;;
-esac
-
-# per-target:
-files="bison_in.hairy"
-links="bison.hairy"
-
-# post-target:
-@end group
-@end example
-@end cartouche
-
-@c ---------------------------------------------------------------------
-@node Install locations
-@section Install locations
-@cindex Where to install
-@cindex Install locations
-
-Using the default configuration, @samp{make install} creates a single tree of
-files, some of which are programs.  The location of this tree is determined by
-the value of the variable @samp{prefix}.  The default value of @samp{prefix} is
-@samp{/usr/local}.  This is often correct for native tools installed on only
-one host.
-
-@menu
-* prefix::            Changing the default install directory
-* exec_prefix::       How to separate host independent files
-                                         from host dependent files when
-                                         installing for multiple hosts
-* Install details::   Full descriptions of all installation subdirectories
-@end menu
-
-@c ---------------------------------------------------------------------
-@node prefix
-@subsection Changing the default install directory
-@cindex Changing the install directory
-@cindex @code{prefix} option
-@vindex prefix
-
-In the default configuration, all files are installed in subdirectories
-of @file{/usr/local}.  The location is determined by the value of
-the @code{configure} variable @samp{prefix}; in turn, this determines the
-value of the @file{Makefile} variable of the same name (@samp{prefix}).
-
-You can also set the value of the @file{Makefile} variable @samp{prefix}
-explicitly each time you invoke @code{make} if you are so inclined.  However,
-because many programs have this location compiled in, you must specify the
-@samp{prefix} value consistently on each invocation of @code{make}, or you will
-end up with a broken installation.
-
-To make this easier, the value of the @code{configure} variable
-@samp{prefix} can be set on the command line to @code{configure}
-using the option @samp{--prefix=}.  
-
-@c ---------------------------------------------------------------------
-@node exec_prefix
-@subsection Installing for multiple hosts
-@cindex Configuring for multiple hosts
-@cindex Sharing host-independent files
-@cindex Installing host-independent files
-@cindex The @code{exec_prefix} directory
-@vindex exec_prefix
-
-By default, host dependent files are installed in subdirectories of
-@file{$(exec_prefix)}.  The location is determined by the value of the
-@code{configure} variable @samp{exec_prefix}, which determines the value of the
-@file{Makefile} variable @samp{exec_prefix}.  This makes it easier to install
-for a single host, and simplifies changing the default location for the install
-tree.  The default doesn't allow for multiple hosts to effectively share
-host independent files, however.
-
-To configure so that multiple hosts can share common files, use something like:
-
-@cindex Example session
-@smallexample
-configure @var{host1} -prefix=/usr/gnu -exec_prefix=/usr/gnu/H-host1
-make all info install install-info clean
-
-configure @var{host2} -prefix=/usr/gnu -exec_prefix=/usr/gnu/H-host2
-make all info install install-info
-@end smallexample
-
-The first line configures the source for @var{host1} to place host-specific
-programs in subdirectories of @file{/usr/gnu/H-@var{host1}}.
-
-The second line builds and installs all programs for @var{host1},
-including both host-independent and host-specific files, as well as removing
-the host-specific object files from of the build directory.
-
-The third line reconfigures the source for @var{host2} to place host
-specific programs in subdirectories of @file{/usr/gnu/H-@var{host2}}.
-
-The fourth line builds and installs all programs for @var{host2}.  Host
-specific files are installed in new directories, but the host
-independent files are installed @emph{on top of} the host
-independent files installed for @var{host1}.  This results in a single
-copy of the host independent files, suitable for use by both hosts.
-
-@xref{Makefile extensions, , Extensions to the @sc{gnu} coding standards}, for
-more information.
-
-@c ---------------------------------------------------------------------
-@node Install details
-@subsection Full descriptions of all installation subdirectories
-@cindex Install details
-@cindex Installation subdirectories
-@cindex Subdirectories
-
-During any install, a number of standard directories are created.  Their names
-are determined by @file{Makefile} variables.  Some of the defaults for
-@file{Makefile} variables can be changed at configuration time using command
-line options to @code{configure}.  For more information on the standard
-directories or the @file{Makefile} variables, please refer to @ref{Makefiles, ,
-Makefile Conventions, standards, GNU Coding Standards}.  See also @ref{Makefile
-extensions, , Extensions to the @sc{gnu} coding standards}.
-
-Note that @code{configure} does not create the directory indicated by the
-variable @samp{srcdir} at any time.  @code{$(srcdir)} is not an installation
-directory.
-
-You can override all @file{Makefile} variables on the command line to
-@code{make}.  (@xref{Overriding, , Overriding Variables, make, GNU Make}.)  If
-you do so, you will need to specify the value precisely the same way for each
-invocation of @code{make}, or you risk ending up with a broken installation.
-This is because many programs have the locations of other programs or files
-compiled into them.  If you find yourself overriding any of the variables
-frequently, you should consider site dependent @file{Makefile} fragments.  See
-also @ref{Sites, , Adding site info}.
-
-During @samp{make install}, a number of standard directories are created and
-populated.  The following @file{Makefile} variables define them.  Those whose
-defaults are set by corresponding @code{configure} variables are marked
-``@code{Makefile} and @code{configure}''.
-
-@table @code
-@item prefix (@code{Makefile} and @code{configure})
-@cindex @code{prefix}
-@vindex prefix
-The root of the installation tree.  You can set its @file{Makefile} default
-with the @samp{--prefix=} command line option to @code{configure}
-(@pxref{Invoking configure, , Invoking @code{configure}}).  The default value
-for @samp{prefix} is @samp{/usr/local}.
-
-@item bindir
-@cindex @code{bindir}
-@vindex bindir
-A directory for binary programs that users can run.  The default value for
-@samp{bindir} depends on @samp{prefix}; @samp{bindir} is normally changed only
-indirectly through @samp{prefix}.  The default value for @samp{bindir} is
-@samp{$(prefix)/bin}.
-
-@item exec_prefix (@code{Makefile} and @code{configure})
-@cindex @code{exec_prefix}
-@vindex exec_prefix
-A directory for host dependent files.  You can specify the @file{Makefile}
-default value by using the @samp{--exec_prefix=} option to @code{configure}.
-(@xref{Invoking configure, , Invoking @code{configure}}.)  The default value
-for @samp{exec_prefix} is @samp{$(prefix)}.
-
-@item libdir
-@cindex @code{libdir}
-@vindex libdir
-A directory for libraries and support programs.  The default value for
-@samp{libdir} depends on @samp{prefix}; @samp{libdir} is normally changed only
-indirectly through @samp{prefix}.  The default value for @samp{libdir} is
-@samp{$(prefix)/lib}.
-
-@item mandir
-@cindex @code{mandir}
-@vindex mandir
-A directory for @code{man} format documentation (``man pages'').  The default
-value for @samp{mandir} depends on @samp{prefix}; @samp{mandir} is normally
-changed only indirectly through @samp{prefix}.  The default value for
-@samp{mandir} is @samp{$(prefix)/man}.
-
-@item man@var{N}dir
-@cindex @code{man@var{N}dir}
-@vindex man@var{N}dir
-These are eight variables named @samp{man1dir}, @samp{man2dir}, etc.  They name
-the specific directories for each man page section.  For example,
-@samp{man1dir} by default holds the filename @file{$(mandir)/man1}; this
-directory contains @file{emacs.1} (the man page for @sc{gnu} Emacs).
-Similarly, @samp{man5dir} contains the value @file{$(mandir)/man5}, indicating
-the directory which holds @file{rcsfile.5} (the man page describing the
-@code{rcs} data file format).  The default value for any of the
-@samp{man@var{N}dir} variables depends indirectly on @samp{prefix}, and is
-normally changed only through @samp{prefix}.  The default value for
-@samp{man@var{N}dir} is @samp{$(mandir)/man@var{N}}.
-
-@item man@var{N}ext
-@cindex @code{man@var{N}ext}
-@vindex man@var{N}ext
-@emph{Not supported by Cygnus @code{configure}}.  The @cite{@sc{gnu} Coding
-Standards} do not call for @samp{man1ext}, @samp{man2ext}, so the intended use
-for @code{manext} is apparently not parallel to @samp{mandir}.  Its use is not
-clear.  (See also @ref{Makefile extensions, , Extensions to the @sc{gnu} coding
-standards}.)
-
-@item infodir
-@cindex @code{infodir}
-@vindex infodir
-A directory for @code{info} format documentation.  The default value for
-@samp{infodir} depends indirectly on @samp{prefix}; @samp{infodir} is
-normally changed only through @samp{prefix}.  The default value for
-@samp{infodir} is @samp{$(prefix)/info}.
-
-@item docdir
-@cindex @code{docdir}
-@vindex docdir
-A directory for any documentation that is in a format other than those used by
-@code{info} or @code{man}.  The default value for @samp{docdir} depends
-indirectly on @samp{prefix}; @samp{docdir} is normally changed only through
-@samp{prefix}.  The default value for @samp{docdir} is @samp{$(datadir)/doc}.
-@emph{This variable is an extension to the @sc{gnu} coding standards}.  (See
-also @ref{Makefile extensions, , Extensions to the @sc{gnu} coding standards}.)
-
-@item includedir
-@cindex @code{includedir}
-@vindex includedir
-A directory for the header files accompanying the libraries installed in
-@samp{libdir}.  The default value for @samp{includedir} depends on
-@samp{prefix}; @samp{includedir} is normally changed only indirectly
-through @samp{prefix}.  The default value for @samp{includedir} is
-@samp{$(prefix)/include}.
-@end table
-
-@c ---------------------------------------------------------------------
-@node Host
-@section Host
-@cindex Host
-
-The arguments to @code{configure} are @dfn{hosttypes}.  By
-@dfn{hosttype} we mean the @dfn{environment} in which the source will be
-compiled.  This need not necessarily be the same as the physical machine
-involved, although it usually is.
-
-For example, if some obscure machine had the @sc{gnu} @code{POSIX} emulation
-libraries available, it would be possible to configure most @sc{gnu} source for
-a @code{POSIX} system and build it on the obscure host.
-
-For more on this topic, see @ref{Host Environments, On Configuring Development
-Tools, Host Environments, cfg-paper, On Configuring Development Tools}.
-
-@c ---------------------------------------------------------------------
-@node Target
-@section Target
-@cindex Target
-
-For building native development tools, or most of the other @sc{gnu}
-tools, you need not worry about the target.  The @dfn{target} of a
-configuration defaults to the same as the @dfn{host}.
-
-For building cross development tools, please see @ref{Building Development
-Environments, On Configuring Development Tools, Building Development
-Environments, cfg-paper, On Configuring Development Tools}.
-
-@c ---------------------------------------------------------------------
-@node Makefile fragments
-@section Adding information about local conventions
-@cindex @code{Makefile} fragments
-@cindex Local conventions
-@cindex Adding local info
-@cindex Adding site info
-
-If you find that a tool does not get configured to your liking, or if
-@code{configure}'s conventions differ from your local conventions, you should
-probably consider @dfn{site-specific @file{Makefile} fragments}.  See also
-@ref{Sites, , Adding site info}.
-
-These are probably not the right choice for options that can be set from
-the @code{configure} command line or for differences that are host or
-target dependent.
-
-Cygnus @code{configure} uses three types of @file{Makefile} fragments.  In a
-generated @file{Makefile} they appear in the order: @dfn{target fragment},
-@dfn{host fragment}, and @dfn{site fragment}.  This allows host fragments to
-override target fragments, and site fragments to override both.
-
-Host-specific @file{Makefile} fragments conventionally reside in the
-@file{./config/} subdirectory with names of the form @file{mh-@var{hosttype}}.
-They are used for hosts that require odd options to the standard compiler and
-for compile time options based on the host configuration.
-
-Target-specific @file{Makefile} fragments conventionally reside in the
-@file{./config/} subdirectory with names of the form @file{mt-@var{target}}.
-They are used for target dependent compile time options.
-
-Site specific @file{Makefile} fragments conventionally reside in the
-@file{./config/} subdirectory with names of the form @file{ms-@var{site}}.
-They are used to override host- and target-independent compile time options.
-Note that you can also override these options on the @code{make} invocation
-line.
-
-@c ---------------------------------------------------------------------
-@node Makefile extensions
-@section Extensions to the @sc{gnu} coding standards
-@cindex @code{Makefile} extensions
-@cindex Cygnus extensions
-@cindex Coding standards extensions
-
-The following additions to the @sc{gnu} coding standards are required for
-Cygnus @code{configure} to work properly.
-
-@itemize @bullet
-@item
-The @file{Makefile} must contain exactly one line starting with @samp{####}.
-This line should follow any default macro definitions but precede any rules.
-Host, target, and site-specific @file{Makefile} fragments will be inserted
-immediately after this line.  If the line is missing, the fragments will not be
-inserted.
-
-@item
-Cygnus adds the following targets to each @file{Makefile}.  Their existence is
-not required for Cygnus @code{configure}, but they are documented here for
-completeness.
-
-@table @code
-@kindex info
-@item info
-Build all info files from texinfo source.
-
-@kindex install-info
-@item install-info
-Install all info files.
-
-@kindex clean-info
-@item clean-info
-Remove all info files and any intermediate files that can be generated
-from texinfo source.
-
-@kindex Makefile
-@item Makefile
-Calls @code{./config.status} to rebuild the @file{Makefile} in this directory.
-@end table
-
-@item
-The following @file{Makefile} targets have revised semantics:
-
-@table @code
-@kindex install
-@item install
-Should @emph{not} depend on the target @samp{all}.  If the program is not
-already built, @samp{make install} should fail.  This allows you to install
-programs even when @code{make} would otherwise determine them to be out of
-date.  This can happen, for example, when the result of a @samp{make all} is
-transported via tape to another machine for installation.
-
-@kindex clean
-@item clean
-Should remove any file that can be regenerated by the @file{Makefile},
-excepting only the @file{Makefile} itself, and any links created by
-@code{configure}.  That is, @code{make all clean} should return all directories
-to their original condition.  If this is not done, then the command sequence
-
-@cindex Example session
-@example
-configure @var{host1} ; make all install clean ; 
-configure @var{host2} ; make all install
-@end example
-
-@noindent
-will fail because of intermediate files intended for @var{host1}.
-@end table
-
-@item
-Cygnus adds the following macros to all @file{Makefile.in} files, but
-you are not required to use them to run Cygnus @code{configure}.
-
-@table @code
-@kindex docdir
-@item docdir
-The directory in which to install any documentation that is not either a
-@code{man} page or an @code{info} file.  For @code{man} pages, see
-@samp{mandir}; for @code{info}, see @samp{infodir}.
-
-@kindex includedir
-@item includedir
-The directory in which to install any header files that should be made
-available to users.  This is distinct from the @code{gcc} include directory,
-which is intended for @code{gcc} only.  Files in @samp{includedir} may be used
-by @code{cc} as well.
-@end table
-
-@item
-The following macros have revised semantics.  Most of them describe
-installation directories; see also @ref{Install details, , Full description of
-all installation subdirectories}.
-
-@table @code
-@kindex datadir
-@item datadir
-is used for host independent data files.
-
-@kindex mandir
-@item mandir
-The default path for @samp{mandir} depends on @samp{prefix}.
-
-@kindex infodir
-@item infodir
-The default path for @samp{infodir} depends on @samp{prefix}.
-
-@kindex BISON
-@item BISON
-is assumed to have a @code{yacc} calling convention.  To use @sc{gnu}
-@code{bison}, use @samp{BISON=bison -y}.
-@end table
-
-@item
-Each Cygnus @file{Makefile} also conforms to one additional restriction:
-
-When libraries are installed, the line containing the call to
-@samp{INSTALL_DATA} should always be followed by a line containing a call to
-@samp{RANLIB} on the installed library.  This is to accommodate systems that
-use @code{ranlib}.  Systems that do not use @code{ranlib} can set @samp{RANLIB}
-to ``@code{echo}'' in a host specific @file{Makefile} fragment.
-@end itemize
-
-@c ========================================================================
-@node Porting
-@chapter Porting with @code{configure}
-@cindex Porting with @code{configure}
-
-This section explains how to add programs, host and target configuration
-names, and site-specific information to Cygnus @code{configure}.
-
-@menu
-* Programs::               Adding configure to new programs
-* Hosts and targets::      Adding hosts and targets
-* Sites::                  Adding site info
-@end menu
-
-@c ---------------------------------------------------------------------
-@node Programs
-@section Adding @code{configure} to new programs
-@cindex Adding @code{configure} to new programs
-
-If you are writing a new program, you probably shouldn't worry about porting or
-configuration issues until it is running reasonably on some host.  Then refer
-back to this section.
-
-If your program currently has a @code{configure} script that meets the @sc{gnu}
-standards (@pxref{Configuration, , How Configuration Should Work, standards,
-GNU Coding Standards}, please do not add Cygnus @code{configure}.  It should be
-possible to add this program without change to a Cygnus @code{configure} style
-source tree.
-
-@cindex @code{autoconf}
-If the program is not target dependent, please consider using @code{autoconf}
-instead of Cygnus @code{configure}.  @code{autoconf} is available from the Free
-Software Foundation; it is a program which generates an executable shell script
-called @file{configure} by automatically finding information on the system to
-be configured on and embedding this information in the shell script.
-@file{configure} scripts generated by @code{autoconf} require no arguments, and
-accept the same options as Cygnus @code{configure}.  For detailed instructions
-on using @code{autoconf}, see @ref{Making configure Scripts, , How to organize
-and produce Autoconf scripts, autoconf, Autoconf}.
-
-
-To add Cygnus @code{configure} to an existing program, do the following:
-
-@table @bullet
-@item Make sure the @file{Makefile} conforms to the @sc{gnu} standard
-The coding standard for writing a @sc{gnu} @file{Makefile} is described in
-@ref{Makefiles, , Makefile Conventions, standards, GNU Coding Standards}.  For
-technical information on writing a @file{Makefile}, see @ref{Makefiles, ,
-Writing Makefiles, make, GNU Make}.
-
-@item Add Cygnus extensions to the @file{Makefile}
-These are described in @ref{Makefile extensions, , Extensions to the @sc{gnu}
-coding standards}.
-
-@item Collect package specific definitions in a single file
-Many packages are best configured using a common @file{Makefile} fragment which
-is included by all of the makefiles in the different directories of the
-package.  In order to accomplish this, set the variable
-@samp{package_makefile_fragment} to the name of the file.  It will be inserted
-into the final @file{Makefile} before the target-specific fragment.
-
-@item Move host support from @file{Makefile} to fragments
-This usually involves finding sections of the @file{Makefile} that say things
-like ``uncomment these lines for host @var{hosttype}'' and moving them to a new
-file called @file{./config/mh-@var{hosttype}}. For more information, see @ref{Hosts
-and targets, , Adding hosts and targets}.
-
-@item Choose defaults
-If the program has compile-time options that determine the way the program
-should behave, choose reasonable defaults and make these @file{Makefile}
-variables.  Be sure the variables are assigned their default values before the
-@samp{####} line so that site-specific @file{Makefile} fragments can override
-them (@pxref{Makefile extensions, , Extensions to the @sc{gnu} coding
-standards}).
-
-@item Locate configuration files
-If there is configuration information in header files or source files, separate
-it in such a way that the files have generic names.  Then move the specific
-instances of those files into the @file{./config/} subdirectory.
-
-@item Separate host and target information
-Some programs already have this information separated.  If yours does not, you
-will need to separate these two kinds of configuration information.  @dfn{Host
-specific} information is the information needed to compile the program.
-@dfn{Target specific} information is information on the format of data files
-that the program will read or write.  This information should live in separate
-files in the @file{./config/} subdirectory with names that reflect the
-configuration for which they are intended.
-
-At this point you might skip this step and simply move on.  If you do, you
-should end up with a program that can be configured only to build @dfn{native}
-tools, that is, tools for which the host system is also the target system.
-Later, you could attempt to build a cross tool and separate out the
-target-specific information by figuring out what went wrong.  This is often
-simpler than combing through all of the source code.
-
-@item Write @code{configure.in}
-Usually this involves writing shell script fragments to map from canonical
-configuration names into the names of the configuration files.  These files
-will then be linked at configure time from the specific instances of those
-files in @file{./config} to files in the build directory with more generic
-names.  (See also @ref{Build directories, , Build directories}.)  The format of
-@file{configure.in} is described in @ref{configure.in, , The
-@code{configure.in} input file}.
-
-@item Rename @file{Makefile} to @file{Makefile.in}
-@end table
-
-At this point you should have a program that can be configured using
-Cygnus @code{configure}.
-
-@c ---------------------------------------------------------------------
-@node Hosts and targets
-@section Adding hosts and targets
-@cindex Adding hosts and targets
-@cindex Hosts and targets
-
-To add a host or target to a program that already uses Cygnus @code{configure},
-do the following.
-
-@itemize @bullet
-
-@item
-Make sure the new configuration name is represented in @file{config.sub}.  If
-not, add it.  For more details, see the comments in the shell script
-@file{config.sub}.
-
-@item
-If you are adding a host configuration, look in @file{configure.in}, in the
-@dfn{per-host} section.  Make sure that your configuration name is represented
-in the mapping from host configuration names to configuration files.  If not,
-add it.  Also see @ref{configure.in, , The @code{configure.in} input file}.
-
-@item
-If you are adding a target configuration, look in @file{configure.in}, in the
-@dfn{per-target} section.  Make sure that your configuration name is
-represented in the mapping from target configuration names to configuration
-files.  If not, add it.  Also see @ref{configure.in, , The @code{configure.in}
-input file}.
-
-@item
-Look in @file{configure.in} for the variables @samp{files}, @samp{links},
-@samp{host_makefile_frag}, and @samp{target_makefile_frag}.  The values
-assigned to these variables are the names of the configuration files, (relative
-to @samp{srcdir}) that the program uses.  Make sure that copies of the files
-exist for your host.  If not, create them.  See also @ref{configure variables,
-, Variables available to @code{configure.in}}.
-@end itemize
-
-This should be enough to @code{configure} for a new host or target
-configuration name.  Getting the program to compile and run properly represents
-the hardest work of any port.
-
-@c ---------------------------------------------------------------------
-@node Sites
-@section Adding site info
-@cindex Sites
-@cindex Adding site info
-
-If some of the @file{Makefile} defaults are not right for your site, you can
-build site-specific @file{Makefile} fragments.  To do this, do the following.
-
-@itemize @bullet
-
-@item
-Choose a name for your site.  It must currently be less than eleven characters.
-
-@item
-If the program source does not have a @file{./config/} subdirectory, create it.
-
-@item
-Create a file called @file{./config/ms-@var{site}} where @var{site} is the name
-of your site.  In it, set whatever @file{Makefile} variables you need to
-override to match your site's conventions.
-
-@item
-Configure the program with:
-
-@cindex Example session
-@example
-configure @dots{} --site=@var{site}
-@end example
-
-@end itemize
-
-@c ---------------------------------------------------------------------
-@node Variables Index
-@unnumbered Variable Index
-
-@printindex vr
-
-@page
-@c ---------------------------------------------------------------------
-@node Concept Index
-@unnumbered Concept Index
-
-@printindex cp
-@contents
-@bye
-
-@c Local Variables:
-@c fill-column: 79
-@c outline-regexp: "@chap"
-@c End:
-@c (setq outline-regexp "@chapt\\\|@unnum\\\|@setf\\\|@conte\\\|@sectio\\\|@subsect\\\|@itemize\\\|@defvar{")
-
diff --git a/gnu/usr.bin/binutils/etc/standards.info-3 b/gnu/usr.bin/binutils/etc/standards.info-3
deleted file mode 100644
index 056b25bba2b..00000000000
--- a/gnu/usr.bin/binutils/etc/standards.info-3
+++ /dev/null
@@ -1,679 +0,0 @@
-This is Info file standards.info, produced by Makeinfo-1.64 from the
-input file ./standards.texi.
-
-START-INFO-DIR-ENTRY
-* Standards: (standards).        GNU coding standards.
-END-INFO-DIR-ENTRY
-
-   GNU Coding Standards Copyright (C) 1992, 1993, 1994, 1995, 1996 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 the Free Software Foundation.
-
-
-File: standards.info,  Node: Directory Variables,  Next: Standard Targets,  Prev: Command Variables,  Up: Makefile Conventions
-
-Variables for Installation Directories
---------------------------------------
-
-   Installation directories should always be named by variables, so it
-is easy to install in a nonstandard place.  The standard names for these
-variables are described below.  They are based on a standard filesystem
-layout; variants of it are used in SVR4, 4.4BSD, Linux, Ultrix v4, and
-other modern operating systems.
-
-   These two variables set the root for the installation.  All the other
-installation directories should be subdirectories of one of these two,
-and nothing should be directly installed into these two directories.
-
-`prefix'
-     A prefix used in constructing the default values of the variables
-     listed below.  The default value of `prefix' should be
-     `/usr/local'.  When building the complete GNU system, the prefix
-     will be empty and `/usr' will be a symbolic link to `/'.  (If you
-     are using Autoconf, write it as `@prefix@'.)
-
-`exec_prefix'
-     A prefix used in constructing the default values of some of the
-     variables listed below.  The default value of `exec_prefix' should
-     be `$(prefix)'.  (If you are using Autoconf, write it as
-     `@exec_prefix@'.)
-
-     Generally, `$(exec_prefix)' is used for directories that contain
-     machine-specific files (such as executables and subroutine
-     libraries), while `$(prefix)' is used directly for other
-     directories.
-
-   Executable programs are installed in one of the following
-directories.
-
-`bindir'
-     The directory for installing executable programs that users can
-     run.  This should normally be `/usr/local/bin', but write it as
-     `$(exec_prefix)/bin'.  (If you are using Autoconf, write it as
-     `@bindir@'.)
-
-`sbindir'
-     The directory for installing executable programs that can be run
-     from the shell, but are only generally useful to system
-     administrators.  This should normally be `/usr/local/sbin', but
-     write it as `$(exec_prefix)/sbin'.  (If you are using Autoconf,
-     write it as `@sbindir@'.)
-
-`libexecdir'
-     The directory for installing executable programs to be run by other
-     programs rather than by users.  This directory should normally be
-     `/usr/local/libexec', but write it as `$(exec_prefix)/libexec'.
-     (If you are using Autoconf, write it as `@libexecdir@'.)
-
-   Data files used by the program during its execution are divided into
-categories in two ways.
-
-   * Some files are normally modified by programs; others are never
-     normally modified (though users may edit some of these).
-
-   * Some files are architecture-independent and can be shared by all
-     machines at a site; some are architecture-dependent and can be
-     shared only by machines of the same kind and operating system;
-     others may never be shared between two machines.
-
-   This makes for six different possibilities.  However, we want to
-discourage the use of architecture-dependent files, aside from object
-files and libraries.  It is much cleaner to make other data files
-architecture-independent, and it is generally not hard.
-
-   Therefore, here are the variables Makefiles should use to specify
-directories:
-
-`datadir'
-     The directory for installing read-only architecture independent
-     data files.  This should normally be `/usr/local/share', but write
-     it as `$(prefix)/share'.  (If you are using Autoconf, write it as
-     `@datadir@'.) As a special exception, see `$(infodir)' and
-     `$(includedir)' below.
-
-`sysconfdir'
-     The directory for installing read-only data files that pertain to a
-     single machine-that is to say, files for configuring a host.
-     Mailer and network configuration files, `/etc/passwd', and so
-     forth belong here.  All the files in this directory should be
-     ordinary ASCII text files.  This directory should normally be
-     `/usr/local/etc', but write it as `$(prefix)/etc'.  (If you are
-     using Autoconf, write it as `@sysconfdir@'.)
-
-     Do not install executables in this directory (they probably belong
-     in `$(libexecdir)' or `$(sbindir)').  Also do not install files
-     that are modified in the normal course of their use (programs
-     whose purpose is to change the configuration of the system
-     excluded).  Those probably belong in `$(localstatedir)'.
-
-`sharedstatedir'
-     The directory for installing architecture-independent data files
-     which the programs modify while they run.  This should normally be
-     `/usr/local/com', but write it as `$(prefix)/com'.  (If you are
-     using Autoconf, write it as `@sharedstatedir@'.)
-
-`localstatedir'
-     The directory for installing data files which the programs modify
-     while they run, and that pertain to one specific machine.  Users
-     should never need to modify files in this directory to configure
-     the package's operation; put such configuration information in
-     separate files that go in `$(datadir)' or `$(sysconfdir)'.
-     `$(localstatedir)' should normally be `/usr/local/var', but write
-     it as `$(prefix)/var'.  (If you are using Autoconf, write it as
-     `@localstatedir@'.)
-
-`libdir'
-     The directory for object files and libraries of object code.  Do
-     not install executables here, they probably ought to go in
-     `$(libexecdir)' instead.  The value of `libdir' should normally be
-     `/usr/local/lib', but write it as `$(exec_prefix)/lib'.  (If you
-     are using Autoconf, write it as `@libdir@'.)
-
-`infodir'
-     The directory for installing the Info files for this package.  By
-     default, it should be `/usr/local/info', but it should be written
-     as `$(prefix)/info'.  (If you are using Autoconf, write it as
-     `@infodir@'.)
-
-`lispdir'
-     The directory for installing any Emacs Lisp files in this package.
-     By default, it should be `/usr/local/share/emacs/site-lisp', but
-     it should be written as `$(prefix)/share/emacs/site-lisp'.
-
-     If you are using Autoconf, write the default as `@lispdir@'.  In
-     order to make `@lispdir@' work, you need the following lines in
-     your `configure.in' file:
-
-          lispdir='${datadir}/emacs/site-lisp'
-          AC_SUBST(lispdir)
-
-`includedir'
-     The directory for installing header files to be included by user
-     programs with the C `#include' preprocessor directive.  This
-     should normally be `/usr/local/include', but write it as
-     `$(prefix)/include'.  (If you are using Autoconf, write it as
-     `@includedir@'.)
-
-     Most compilers other than GCC do not look for header files in
-     `/usr/local/include'.  So installing the header files this way is
-     only useful with GCC.  Sometimes this is not a problem because some
-     libraries are only really intended to work with GCC.  But some
-     libraries are intended to work with other compilers.  They should
-     install their header files in two places, one specified by
-     `includedir' and one specified by `oldincludedir'.
-
-`oldincludedir'
-     The directory for installing `#include' header files for use with
-     compilers other than GCC.  This should normally be `/usr/include'.
-     (If you are using Autoconf, you can write it as `@oldincludedir@'.)
-
-     The Makefile commands should check whether the value of
-     `oldincludedir' is empty.  If it is, they should not try to use
-     it; they should cancel the second installation of the header files.
-
-     A package should not replace an existing header in this directory
-     unless the header came from the same package.  Thus, if your Foo
-     package provides a header file `foo.h', then it should install the
-     header file in the `oldincludedir' directory if either (1) there
-     is no `foo.h' there or (2) the `foo.h' that exists came from the
-     Foo package.
-
-     To tell whether `foo.h' came from the Foo package, put a magic
-     string in the file--part of a comment--and `grep' for that string.
-
-   Unix-style man pages are installed in one of the following:
-
-`mandir'
-     The top-level directory for installing the man pages (if any) for
-     this package.  It will normally be `/usr/local/man', but you should
-     write it as `$(prefix)/man'.  (If you are using Autoconf, write it
-     as `@mandir@'.)
-
-`man1dir'
-     The directory for installing section 1 man pages.  Write it as
-     `$(mandir)/man1'.
-
-`man2dir'
-     The directory for installing section 2 man pages.  Write it as
-     `$(mandir)/man2'
-
-`...'
-     *Don't make the primary documentation for any GNU software be a
-     man page.  Write a manual in Texinfo instead.  Man pages are just
-     for the sake of people running GNU software on Unix, which is a
-     secondary application only.*
-
-`manext'
-     The file name extension for the installed man page.  This should
-     contain a period followed by the appropriate digit; it should
-     normally be `.1'.
-
-`man1ext'
-     The file name extension for installed section 1 man pages.
-
-`man2ext'
-     The file name extension for installed section 2 man pages.
-
-`...'
-     Use these names instead of `manext' if the package needs to
-     install man pages in more than one section of the manual.
-
-   And finally, you should set the following variable:
-
-`srcdir'
-     The directory for the sources being compiled.  The value of this
-     variable is normally inserted by the `configure' shell script.
-     (If you are using Autconf, use `srcdir = @srcdir@'.)
-
-   For example:
-
-     # Common prefix for installation directories.
-     # NOTE: This directory must exist when you start the install.
-     prefix = /usr/local
-     exec_prefix = $(prefix)
-     # Where to put the executable for the command `gcc'.
-     bindir = $(exec_prefix)/bin
-     # Where to put the directories used by the compiler.
-     libexecdir = $(exec_prefix)/libexec
-     # Where to put the Info files.
-     infodir = $(prefix)/info
-
-   If your program installs a large number of files into one of the
-standard user-specified directories, it might be useful to group them
-into a subdirectory particular to that program.  If you do this, you
-should write the `install' rule to create these subdirectories.
-
-   Do not expect the user to include the subdirectory name in the value
-of any of the variables listed above.  The idea of having a uniform set
-of variable names for installation directories is to enable the user to
-specify the exact same values for several different GNU packages.  In
-order for this to be useful, all the packages must be designed so that
-they will work sensibly when the user does so.
-
-
-File: standards.info,  Node: Standard Targets,  Next: Install Command Categories,  Prev: Directory Variables,  Up: Makefile Conventions
-
-Standard Targets for Users
---------------------------
-
-   All GNU programs should have the following targets in their
-Makefiles:
-
-`all'
-     Compile the entire program.  This should be the default target.
-     This target need not rebuild any documentation files; Info files
-     should normally be included in the distribution, and DVI files
-     should be made only when explicitly asked for.
-
-     By default, the Make rules should compile and link with `-g', so
-     that executable programs have debugging symbols.  Users who don't
-     mind being helpless can strip the executables later if they wish.
-
-`install'
-     Compile the program and copy the executables, libraries, and so on
-     to the file names where they should reside for actual use.  If
-     there is a simple test to verify that a program is properly
-     installed, this target should run that test.
-
-     Do not strip executables when installing them.  Devil-may-care
-     users can use the `install-strip' target to do that.
-
-     If possible, write the `install' target rule so that it does not
-     modify anything in the directory where the program was built,
-     provided `make all' has just been done.  This is convenient for
-     building the program under one user name and installing it under
-     another.
-
-     The commands should create all the directories in which files are
-     to be installed, if they don't already exist.  This includes the
-     directories specified as the values of the variables `prefix' and
-     `exec_prefix', as well as all subdirectories that are needed.  One
-     way to do this is by means of an `installdirs' target as described
-     below.
-
-     Use `-' before any command for installing a man page, so that
-     `make' will ignore any errors.  This is in case there are systems
-     that don't have the Unix man page documentation system installed.
-
-     The way to install Info files is to copy them into `$(infodir)'
-     with `$(INSTALL_DATA)' (*note Command Variables::.), and then run
-     the `install-info' program if it is present.  `install-info' is a
-     program that edits the Info `dir' file to add or update the menu
-     entry for the given Info file; it is part of the Texinfo package.
-     Here is a sample rule to install an Info file:
-
-          $(infodir)/foo.info: foo.info
-                  $(POST_INSTALL)
-          # There may be a newer info file in . than in srcdir.
-                  -if test -f foo.info; then d=.; \
-                   else d=$(srcdir); fi; \
-                  $(INSTALL_DATA) $$d/foo.info $@; \
-          # Run install-info only if it exists.
-          # Use `if' instead of just prepending `-' to the
-          # line so we notice real errors from install-info.
-          # We use `$(SHELL) -c' because some shells do not
-          # fail gracefully when there is an unknown command.
-                  if $(SHELL) -c 'install-info --version' \
-                     >/dev/null 2>&1; then \
-                    install-info --dir-file=$(infodir)/dir \
-                                 $(infodir)/foo.info; \
-                  else true; fi
-
-     When writing the `install' target, you must classify all the
-     commands into three categories: normal ones, "pre-installation"
-     commands and "post-installation" commands.  *Note Install Command
-     Categories::.
-
-`uninstall'
-     Delete all the installed files--the copies that the `install'
-     target creates.
-
-     This rule should not modify the directories where compilation is
-     done, only the directories where files are installed.
-
-     The uninstallation commands are divided into three categories,
-     just like the installation commands.  *Note Install Command
-     Categories::.
-
-`install-strip'
-     Like `install', but strip the executable files while installing
-     them.  In many cases, the definition of this target can be very
-     simple:
-
-          install-strip:
-                  $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
-                          install
-
-     Normally we do not recommend stripping an executable unless you
-     are sure the program has no bugs.  However, it can be reasonable
-     to install a stripped executable for actual execution while saving
-     the unstripped executable elsewhere in case there is a bug.
-
-`clean'
-     Delete all files from the current directory that are normally
-     created by building the program.  Don't delete the files that
-     record the configuration.  Also preserve files that could be made
-     by building, but normally aren't because the distribution comes
-     with them.
-
-     Delete `.dvi' files here if they are not part of the distribution.
-
-`distclean'
-     Delete all files from the current directory that are created by
-     configuring or building the program.  If you have unpacked the
-     source and built the program without creating any other files,
-     `make distclean' should leave only the files that were in the
-     distribution.
-
-`mostlyclean'
-     Like `clean', but may refrain from deleting a few files that people
-     normally don't want to recompile.  For example, the `mostlyclean'
-     target for GCC does not delete `libgcc.a', because recompiling it
-     is rarely necessary and takes a lot of time.
-
-`maintainer-clean'
-     Delete almost everything from the current directory that can be
-     reconstructed with this Makefile.  This typically includes
-     everything deleted by `distclean', plus more: C source files
-     produced by Bison, tags tables, Info files, and so on.
-
-     The reason we say "almost everything" is that running the command
-     `make maintainer-clean' should not delete `configure' even if
-     `configure' can be remade using a rule in the Makefile.  More
-     generally, `make maintainer-clean' should not delete anything that
-     needs to exist in order to run `configure' and then begin to build
-     the program.  This is the only exception; `maintainer-clean' should
-     delete everything else that can be rebuilt.
-
-     The `maintainer-clean' target is intended to be used by a
-     maintainer of the package, not by ordinary users.  You may need
-     special tools to reconstruct some of the files that `make
-     maintainer-clean' deletes.  Since these files are normally
-     included in the distribution, we don't take care to make them easy
-     to reconstruct.  If you find you need to unpack the full
-     distribution again, don't blame us.
-
-     To help make users aware of this, the commands for the special
-     `maintainer-clean' target should start with these two:
-
-          @echo 'This command is intended for maintainers to use; it'
-          @echo 'deletes files that may need special tools to rebuild.'
-
-`TAGS'
-     Update a tags table for this program.
-
-`info'
-     Generate any Info files needed.  The best way to write the rules
-     is as follows:
-
-          info: foo.info
-          
-          foo.info: foo.texi chap1.texi chap2.texi
-                  $(MAKEINFO) $(srcdir)/foo.texi
-
-     You must define the variable `MAKEINFO' in the Makefile.  It should
-     run the `makeinfo' program, which is part of the Texinfo
-     distribution.
-
-     Normally a GNU distribution comes with Info files, and that means
-     the Info files are present in the source directory.  Therefore,
-     the Make rule for an info file should update it in the source
-     directory.  When users build the package, ordinarily Make will not
-     update the Info files because they will already be up to date.
-
-`dvi'
-     Generate DVI files for all Texinfo documentation.  For example:
-
-          dvi: foo.dvi
-          
-          foo.dvi: foo.texi chap1.texi chap2.texi
-                  $(TEXI2DVI) $(srcdir)/foo.texi
-
-     You must define the variable `TEXI2DVI' in the Makefile.  It should
-     run the program `texi2dvi', which is part of the Texinfo
-     distribution.(1)  Alternatively, write just the dependencies, and
-     allow GNU `make' to provide the command.
-
-`dist'
-     Create a distribution tar file for this program.  The tar file
-     should be set up so that the file names in the tar file start with
-     a subdirectory name which is the name of the package it is a
-     distribution for.  This name can include the version number.
-
-     For example, the distribution tar file of GCC version 1.40 unpacks
-     into a subdirectory named `gcc-1.40'.
-
-     The easiest way to do this is to create a subdirectory
-     appropriately named, use `ln' or `cp' to install the proper files
-     in it, and then `tar' that subdirectory.
-
-     Compress the tar file file with `gzip'.  For example, the actual
-     distribution file for GCC version 1.40 is called `gcc-1.40.tar.gz'.
-
-     The `dist' target should explicitly depend on all non-source files
-     that are in the distribution, to make sure they are up to date in
-     the distribution.  *Note Making Releases: Releases.
-
-`check'
-     Perform self-tests (if any).  The user must build the program
-     before running the tests, but need not install the program; you
-     should write the self-tests so that they work when the program is
-     built but not installed.
-
-   The following targets are suggested as conventional names, for
-programs in which they are useful.
-
-`installcheck'
-     Perform installation tests (if any).  The user must build and
-     install the program before running the tests.  You should not
-     assume that `$(bindir)' is in the search path.
-
-`installdirs'
-     It's useful to add a target named `installdirs' to create the
-     directories where files are installed, and their parent
-     directories.  There is a script called `mkinstalldirs' which is
-     convenient for this; you can find it in the Texinfo package.  You
-     can use a rule like this:
-
-          # Make sure all installation directories (e.g. $(bindir))
-          # actually exist by making them if necessary.
-          installdirs: mkinstalldirs
-                  $(srcdir)/mkinstalldirs $(bindir) $(datadir) \
-                                          $(libdir) $(infodir) \
-                                          $(mandir)
-
-     This rule should not modify the directories where compilation is
-     done.  It should do nothing but create installation directories.
-
-   ---------- Footnotes ----------
-
-   (1)  `texi2dvi' uses TeX to do the real work of formatting. TeX is
-not distributed with Texinfo.
-
-
-File: standards.info,  Node: Install Command Categories,  Prev: Standard Targets,  Up: Makefile Conventions
-
-Install Command Categories
---------------------------
-
-   When writing the `install' target, you must classify all the
-commands into three categories: normal ones, "pre-installation"
-commands and "post-installation" commands.
-
-   Normal commands move files into their proper places, and set their
-modes.  They may not alter any files except the ones that come entirely
-from the package they belong to.
-
-   Pre-installation and post-installation commands may alter other
-files; in particular, they can edit global configuration files or data
-bases.
-
-   Pre-installation commands are typically executed before the normal
-commands, and post-installation commands are typically run after the
-normal commands.
-
-   The most common use for a post-installation command is to run
-`install-info'.  This cannot be done with a normal command, since it
-alters a file (the Info directory) which does not come entirely and
-solely from the package being installed.  It is a post-installation
-command because it needs to be done after the normal command which
-installs the package's Info files.
-
-   Most programs don't need any pre-installation commands, but we have
-the feature just in case it is needed.
-
-   To classify the commands in the `install' rule into these three
-categories, insert "category lines" among them.  A category line
-specifies the category for the commands that follow.
-
-   A category line consists of a tab and a reference to a special Make
-variable, plus an optional comment at the end.  There are three
-variables you can use, one for each category; the variable name
-specifies the category.  Category lines are no-ops in ordinary execution
-because these three Make variables are normally undefined (and you
-*should not* define them in the makefile).
-
-   Here are the three possible category lines, each with a comment that
-explains what it means:
-
-             $(PRE_INSTALL)     # Pre-install commands follow.
-             $(POST_INSTALL)    # Post-install commands follow.
-             $(NORMAL_INSTALL)  # Normal commands follow.
-
-   If you don't use a category line at the beginning of the `install'
-rule, all the commands are classified as normal until the first category
-line.  If you don't use any category lines, all the commands are
-classified as normal.
-
-   These are the category lines for `uninstall':
-
-             $(PRE_UNINSTALL)     # Pre-uninstall commands follow.
-             $(POST_UNINSTALL)    # Post-uninstall commands follow.
-             $(NORMAL_UNINSTALL)  # Normal commands follow.
-
-   Typically, a pre-uninstall command would be used for deleting entries
-from the Info directory.
-
-   If the `install' or `uninstall' target has any dependencies which
-act as subroutines of installation, then you should start *each*
-dependency's commands with a category line, and start the main target's
-commands with a category line also.  This way, you can ensure that each
-command is placed in the right category regardless of which of the
-dependencies actually run.
-
-   Pre-installation and post-installation commands should not run any
-programs except for these:
-
-     [ basename bash cat chgrp chmod chown cmp cp dd diff echo
-     egrep expand expr false fgrep find getopt grep gunzip gzip
-     hostname install install-info kill ldconfig ln ls md5sum
-     mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee
-     test touch true uname xargs yes
-
-   The reason for distinguishing the commands in this way is for the
-sake of making binary packages.  Typically a binary package contains
-all the executables and other files that need to be installed, and has
-its own method of installing them--so it does not need to run the normal
-installation commands.  But installing the binary package does need to
-execute the pre-installation and post-installation commands.
-
-   Programs to build binary packages work by extracting the
-pre-installation and post-installation commands.  Here is one way of
-extracting the pre-installation commands:
-
-     make -n install -o all \
-           PRE_INSTALL=pre-install \
-           POST_INSTALL=post-install \
-           NORMAL_INSTALL=normal-install \
-       | gawk -f pre-install.awk
-
-where the file `pre-install.awk' could contain this:
-
-     $0 ~ /^\t[ \t]*(normal_install|post_install)[ \t]*$/ {on = 0}
-     on {print $0}
-     $0 ~ /^\t[ \t]*pre_install[ \t]*$/ {on = 1}
-
-   The resulting file of pre-installation commands is executed as a
-shell script as part of installing the binary package.
-
-
-File: standards.info,  Node: Releases,  Prev: Makefile Conventions,  Up: Managing Releases
-
-Making Releases
-===============
-
-   Package the distribution of Foo version 69.96 in a gzipped tar file
-named `foo-69.96.tar.gz'.  It should unpack into a subdirectory named
-`foo-69.96'.
-
-   Building and installing the program should never modify any of the
-files contained in the distribution.  This means that all the files
-that form part of the program in any way must be classified into "source
-files" and "non-source files".  Source files are written by humans and
-never changed automatically; non-source files are produced from source
-files by programs under the control of the Makefile.
-
-   Naturally, all the source files must be in the distribution.  It is
-okay to include non-source files in the distribution, provided they are
-up-to-date and machine-independent, so that building the distribution
-normally will never modify them.  We commonly include non-source files
-produced by Bison, `lex', TeX, and `makeinfo'; this helps avoid
-unnecessary dependencies between our distributions, so that users can
-install whichever packages they want to install.
-
-   Non-source files that might actually be modified by building and
-installing the program should *never* be included in the distribution.
-So if you do distribute non-source files, always make sure they are up
-to date when you make a new distribution.
-
-   Make sure that the directory into which the distribution unpacks (as
-well as any subdirectories) are all world-writable (octal mode 777).
-This is so that old versions of `tar' which preserve the ownership and
-permissions of the files from the tar archive will be able to extract
-all the files even if the user is unprivileged.
-
-   Make sure that all the files in the distribution are world-readable.
-
-   Make sure that no file name in the distribution is more than 14
-characters long.  Likewise, no file created by building the program
-should have a name longer than 14 characters.  The reason for this is
-that some systems adhere to a foolish interpretation of the POSIX
-standard, and refuse to open a longer name, rather than truncating as
-they did in the past.
-
-   Don't include any symbolic links in the distribution itself.  If the
-tar file contains symbolic links, then people cannot even unpack it on
-systems that don't support symbolic links.  Also, don't use multiple
-names for one file in different directories, because certain file
-systems cannot handle this and that prevents unpacking the distribution.
-
-   Try to make sure that all the file names will be unique on MS-DOS.  A
-name on MS-DOS consists of up to 8 characters, optionally followed by a
-period and up to three characters.  MS-DOS will truncate extra
-characters both before and after the period.  Thus, `foobarhacker.c'
-and `foobarhacker.o' are not ambiguous; they are truncated to
-`foobarha.c' and `foobarha.o', which are distinct.
-
-   Include in your distribution a copy of the `texinfo.tex' you used to
-test print any `*.texinfo' or `*.texi' files.
-
-   Likewise, if your program uses small GNU software packages like
-regex, getopt, obstack, or termcap, include them in the distribution
-file.  Leaving them out would make the distribution file a little
-smaller at the expense of possible inconvenience to a user who doesn't
-know what other files to get.
-
-