Update to gcc 2.95.1, official release.

16 files changed, 1810 insertions, 0 deletions

diff --git a/gnu/egcs/install/BUILD b/gnu/egcs/install/BUILD
new file mode 100644
index 00000000000..6bf0322b9c4
--- /dev/null
+++ b/gnu/egcs/install/BUILD
@@ -0,0 +1,82 @@
+
+                          Installing GCC: Building
+                                      
+   Now that GCC is configured, you are ready to build the compiler and
+   runtime libraries.
+   
+   We _highly_ recommend that GCC be built using GNU make; other versions
+   may work, then again they might not. To be safe build with GNU make.
+   
+Building a native compiler
+
+   For a native build issue the command `make bootstrap'. This will build
+   the entire GCC system, which includes the following steps:
+     * Build host tools necessary to build the compiler such as texinfo,
+       bison, gperf.
+     * Build target tools for use by the compiler such as gas, gld, and
+       binutils if they have been properly unpacked into the GCC source
+       tree.
+     * Perform a 3-stage bootstrap of the compiler.
+     * Perform a comparison test of the stage2 and stage3 compilers.
+     * Build runtime libraries using the stage3 compiler from the
+       previous step.
+       
+   If you are short on disk space you might consider `make
+   bootstrap-lean' instead. This is identical to `make bootstrap' except
+   that object files from the stage1 and stage2 of the 3-stage bootstrap
+   of the compiler are deleted as soon as they are no longer needed.
+   
+   If you want to save additional space during the bootstrap and in the
+   final installation as well, you can build the compiler binaries
+   without debugging information with "make CFLAGS='-O' LIBCFLAGS='-g
+   -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap". This
+   will save roughly 40% of disk space both for the bootstrap and the
+   final installation. (Libraries will still contain debugging
+   information.)
+   
+   If you used the flag --enable-languages=... to restrict the compilers
+   to be built, only those you've actually enabled will be built. This
+   will of course only build those runtime libraries, for which the
+   particular compiler has been built. Please note, that re-defining
+   LANGUAGES when calling `make bootstrap' _*does not*_ work anymore!
+   
+Building a cross compiler
+
+   We recommend reading the [1]crossgcc FAQ for information about
+   building cross compilers.
+   
+   When building a cross compiler, it is not generally possible to do a
+   3-stage bootstrap of the compiler. This makes for an interesting
+   problem as parts of GCC can only be built with GCC.
+   
+   To build a cross compiler, we first recommend building and installing
+   a native compiler. You can then use the native GCC compiler to build
+   the cross compiler.
+   
+   Assuming you have already installed a native copy of GCC and
+   configured your corss compiler, issue the command "make", which
+   performs the following steps:
+     * Build host tools necessary to build the compiler such as texinfo,
+       bison, gperf.
+     * Build target tools for use by the compiler such as gas, gld, and
+       binutils if they have been properly unpacked into the GCC source
+       tree.
+     * Build the compiler (single stage only).
+     * Build runtime libraries using the compiler from the previous step.
+       
+   Note that if an error occurs in any step the make process will exit.
+   
+Building in parallel
+
+   If you have a multiprocessor you can use `make bootstrap MAKE="make -j
+   2" -j 2' instead of just `make bootstrap' when building GCC. You can
+   use a bigger number instead of two if you like. In most cases, it
+   won't help to use a number bigger than the number of processors in
+   your machine.
+     _________________________________________________________________
+   
+   _Last modified on July 16, 1999._
+
+References
+
+   1. http://www.objsw.com/CrossGCC/
diff --git a/gnu/egcs/install/CONFIGURE b/gnu/egcs/install/CONFIGURE
new file mode 100644
index 00000000000..9f88368b332
--- /dev/null
+++ b/gnu/egcs/install/CONFIGURE
@@ -0,0 +1,137 @@
+
+                       Installing GCC: Configuration
+                                      
+   Like most GNU software, GCC must be configured before it can be built.
+   This document describes the recommended configuration procedure for
+   both native and cross targets.
+   
+   We use _srcdir_ to refer to the toplevel source directory for GCC; we
+   use _objdir_ to refer to the toplevel build/object directory.
+   
+   First, we _highly_ recommend that GCC be built into a separate
+   directory than the sources which does _not_ reside within the source
+   tree. This is how we generally build GCC; building where _srcdir_ ==
+   _objdir_ should still work, but doesn't get extensive testing;
+   building where _objdir_ is a subdirectory of _srcdir_ is unsupported.
+   
+   Second, when configuring a native system, either "cc" or "gcc" must be
+   in your path or you must set CC in your environment before running
+   configure. Otherwise the configuration scripts may fail.
+   
+   To configure GCC:
+   
+     % mkdir _objdir_
+     % cd _objdir_
+     % _srcdir_/configure _[target]_ _[options]_
+     
+   _target specification_
+     * GCC has code to correctly determine the correct value for _target_
+       for nearly all native systems. Therefore, we highly recommend you
+       not provide a configure target when configuring a native compiler.
+     * _target_ must be specified when configuring a cross compiler;
+       examples of valid targets would be i960-rtems, m68k-coff, sh-elf,
+       etc.
+       
+   _options specification_
+   
+   Use _options_ to override several configure time options for GCC. A
+   partial list of supported options:
+     * --prefix=_dirname_ -- Specify the toplevel installation directory.
+       This is the recommended way to install the tools into a directory
+       other than the default. The toplevel installation directory
+       defaults to /usr/local.
+       We _highly_ recommend against _prefix_ being the same or a
+       subdirectory of _objdir_ or vice versa.
+       These additional options control where certain parts of the
+       distribution are installed. Normally you should not need to use
+       these options.
+          + --with-local-prefix=_dirname_ -- Specify the installation
+            directory for local include files. The default is /usr/local.
+          + --with-gxx-include-dir=_dirname_ -- Specify the installation
+            directory for g++ header files. The default is
+            /usr/local/include/g++.
+     * --enable-shared -- Build shared versions of the C++ runtime
+       libraries if supported --disable-shared is the default.
+     * --enable-haifa -- Enable the new Haifa instruction scheduler in
+       the compiler; the new scheduler can significantly improve code on
+       some targets.
+       For EGCS 1.0.x releases --disable-haifa is the default on all
+       platforms except the HPPA.
+       For newer releases --disable-haifa is the default on all platforms
+       except the alpha, hppa, powerpc, rs6000, SPARC and m32r.
+     * --with-gnu-as -- Specify that the compiler should assume the GNU
+       assembler (aka gas) is available.
+     * --with-gnu-ld -- Specify that the compiler should assume the GNU
+       linker (aka gld) is available.
+     * --with-stabs -- Specify that stabs debugging information should be
+       used instead of whatever format the host normally uses. Normally
+       GCC uses the same debug format as the host system.
+     * --enable-multilib -- Specify that multiple target libraries should
+       be built to support different target variants, calling
+       conventions, etc. This is the default.
+     * --enable-threads -- Specify that the target supports threads. This
+       affects only the Objective-C compiler and runtime library.
+     * --enable-threads=_lib_ -- Specify that _lib_ is the thread support
+       library. This affects only the Objective-C compiler and runtime
+       library.
+     * --with-cpu=_cpu_ -- Specify which cpu variant the compiler should
+       generate code for by default. This is currently only supported on
+       the some ports, specifically arm, powerpc, and SPARC. If configure
+       does not recognize the model name (e.g. arm700, 603e, or
+       ultrasparc) you provide, please check the configure script for a
+       complete list of supported models.
+     * --enable-target-optspace -- Specify that target libraries should
+       be optimzied for code space instead of code speed. This is the
+       default for the m32r platform.
+     * --enable-cpp -- Specify that a shell script which emulates
+       traditional cpp functionality should be installed.
+     * --enable-cpplib -- Specify that the functionality of CPP should be
+       integrated into the compiler itself. This is still under
+       development, but may be useful in limited situations. This option
+       is never enabled by default.
+     * --without-fast-fixincludes -- Specify that the old, slower method
+       of fixing the system header files should be used. EGCS 1.1.x and
+       older releases default to the slow version. GCC 2.95 and newer
+       releases will default to the fast version.
+     * --enable-version-specific-runtime-libs -- Specify that runtime
+       libraries should be installed in the compiler specific
+       subdirectory (${libsubdir}) rather than the usual places. In
+       addition, libstdc++'s include files will be installed in
+       ${libsubdir}/include/g++ unless you overruled it by using
+       --with-gxx-include-dir=_dirname_. Using this option is
+       particularly useful if you intend to use several versions of
+       egcs/gcc in parallel. This is currently supported by libf2c and
+       libstdc++.
+     * --enable-languages=_lang1_,_lang2_,... -- Specify that only a
+       particular subset of compilers and their runtime libraries should
+       be built. For a list of valid values for _lang_x you can issue the
+       following command in the gcc directory of your GCC source tree:
+       grep language= */config-lang.in
+       Currently, you can use any of the following: CHILL, c++, f77, java
+       and objc. Please note, that this switch does not work with EGCS
+       1.1.2 or older versions of egcs. It will be supported in GCC 2.95
+       and newer version.
+       If you do not pass this flag, all languages available in the gcc
+       sub-tree will be configured. Re-defining LANGUAGES when calling
+       make bootstrap _*does not*_ work anymore, as those language
+       sub-directories might not have been configured!
+     * --with-dwarf2 -- Specify that the compiler should use DWARF2
+       debugging information as the default.
+       
+   Some options which only apply to building cross compilers:
+     * --with-headers=_dir_ -- Specifies a directory which has target
+       include files. These include files will be copied into the gcc
+       install directory. Fixincludes will be run on these files to make
+       them compatible with gcc.
+     * --with-libs=_"dir1 dir2 ... dirN"_ -- Specifies a list of
+       directories which contain the target runtime libraries. These
+       libraries will be copied into the gcc install directory.
+     * --with-newlib -- Specifies that "newlib" is being used as the
+       target C library. This causes __eprintf to be omitted from
+       libgcc.a on the assumption that it will be provided by newlib.
+       
+   Note that each --enable option has a corresponding --disable option
+   and that each --with option has a corresponding --without option.
+     _________________________________________________________________
+   
+   _Last modified on July 16, 1999._
diff --git a/gnu/egcs/install/DOWNLOAD b/gnu/egcs/install/DOWNLOAD
new file mode 100644
index 00000000000..18036253bc9
--- /dev/null
+++ b/gnu/egcs/install/DOWNLOAD
@@ -0,0 +1,39 @@
+
+                              Downloading GCC
+                                      
+   GCC is distributed via FTP tarballs compressed with gzip or bzip2. It
+   is possible to download a full distribution or specific components.
+   
+   The full distribution includes the C, C++, Objective-C, Fortran, Java,
+   and Chill compilers. The full distribution also includes runtime
+   libraries for C++, Objective-C and Fortran. In the future the GNU
+   compiler testsuites will be included in the full distribution.
+   
+   If you choose to download specific components, you must download the
+   core gcc distribution plus any language specific distributions you
+   wish to use. The core distribution includes the C language front-end
+   as well as the shared componenets. Each language has a tarball which
+   includes the language front-end as well as the language runtime (when
+   appropriate).
+   
+   Unpack the core distribution as well as any language specific
+   distributions in the same directory.
+   
+   XXX FSF mirror sites
+   
+   [1]FTP download from egcs.cygnus.com (USA California)
+   
+   [2]FTP download from go.cygnus.com (USA California -- High speed link
+   provided by Stanford)
+   
+   GCC releases are available on many [3]FTP mirror sites. If possible,
+   please use one of these.
+     _________________________________________________________________
+   
+   _Last modified on July 16, 1999._
+
+References
+
+   1. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+   2. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+   3. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/mirrors.html
diff --git a/gnu/egcs/install/FINALINSTALL b/gnu/egcs/install/FINALINSTALL
new file mode 100644
index 00000000000..9092666ffae
--- /dev/null
+++ b/gnu/egcs/install/FINALINSTALL
@@ -0,0 +1,29 @@
+
+                     Installing GCC: Final installation
+                                      
+   Now that GCC has been built and tested, you can install it with `cd
+   _objdir_; make install' for a native compiler or `cd _objdir_; make
+   install LANGUAGES="c c++"' for a cross compiler (note installing cross
+   compilers will be easier in the next release!).
+   
+   That step completes the installation of GCC; user level binaries can
+   be found in _prefix_/bin where _prefix_ is the value you specified
+   with the --prefix to configure (or /usr/local by default).
+   
+   If you don't mind, please quickly review the [1]build status page. If
+   your system is not listed, send a note to [2]gcc@gcc.gnu.org
+   indicating that you successfully built and installed GCC. Include the
+   output from running _srcdir_/config.guess. (Do not send us the
+   config.guess file itself, just the output from running it!)
+   
+   If you find a bug, please report it following our [3]bug reporting
+   guidlines.
+     _________________________________________________________________
+   
+   _Last modified on July 16, 1999._
+
+References
+
+   1. http://egcs.cygnus.com/gcc-2.95/buildstat.html
+   2. mailto:gcc@gcc.gnu.org
+   3. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/faq.html#bugreport
diff --git a/gnu/egcs/install/INDEX b/gnu/egcs/install/INDEX
new file mode 100644
index 00000000000..baf49be2b50
--- /dev/null
+++ b/gnu/egcs/install/INDEX
@@ -0,0 +1,51 @@
+
+                               Installing GCC
+                                      
+   The latest version of this document is always available at
+   [1]http://egcs.cygnus.com/install/.
+   
+   This document describes the generic installation procedure for GCC as
+   well as detailing some target specific installation instructions.
+   
+   GCC includes several components that previously were separate
+   distributions with their own installation instructions. This document
+   supercedes all package specific installation instructions. We provide
+   the component specific installation information in the source
+   distribution for historical reference purposes only.
+   
+   We recommend you read the entire generic installation instructions as
+   well as any target specific installation instructions before you
+   proceed to configure, build, test and install GCC.
+   
+   If something goes wrong in the configure, build, test or install
+   procedures, first double check that you followed the generic and
+   target specific installation instructions carefully. Then check the
+   [2]FAQ to see if your problem is covered before you file a bug report.
+   
+   _Before_ starting the build/install procedure _please_ browse the
+   [3]host/target specific installation notes.
+   
+   The installation procedure is broken into five steps.
+     * [4]downloading the source
+     * [5]configure
+     * [6]build
+     * [7]test (optional)
+     * [8]install
+     _________________________________________________________________
+   
+   [9]Return to the GCC home page
+     _________________________________________________________________
+   
+   _Last modified on July 15, 1999._
+
+References
+
+   1. http://egcs.cygnus.com/install/
+   2. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/faq.html
+   3. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html
+   4. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/download.html
+   5. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/configure.html
+   6. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/build.html
+   7. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/test.html
+   8. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/finalinstall.html
+   9. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/index.html
diff --git a/gnu/egcs/install/SPECIFIC b/gnu/egcs/install/SPECIFIC
new file mode 100644
index 00000000000..e7a5db8c6e7
--- /dev/null
+++ b/gnu/egcs/install/SPECIFIC
@@ -0,0 +1,497 @@
+
+              Host/Target specific installation notes for GCC
+                                      
+   Please read this document carefully _before_ installing the GNU
+   Compiler Collection on your machine.
+     * [1]alpha*-dec-osf*
+     * [2]hppa*-hp-hpux*
+     * [3]hppa*-hp-hpux9
+     * [4]hppa*-hp-hpux10
+     * [5]i?86-*-linux*
+     * [6]i?86-*-sco3.2v5*
+     * [7]i?86-*-udk
+     * [8]*-ibm-aix*
+     * [9]m68k-*-nextstep*
+     * [10]m68k-sun-sunos4.1.1
+     * [11]mips*-sgi-irix[45]
+     * [12]mips*-sgi-irix6
+     * [13]powerpc-*-linux-gnu*
+     * [14]sparc-sun-solaris2.7
+     * [15]sparc-sun-sunos*
+     * [16]sparc-unknown-linux-gnulibc1
+     * [17]sparc64-*-*
+     * [18]GCC with Windows or OS/2
+     _________________________________________________________________
+   
+  alpha*-dec-linux*
+  
+   GNU/Linux Alpha EV56 or PCA56 hosts running Red Hat 4.2 or 5.0 may see
+   errors of this sort:
+  Error: Unknown pseudo-op:  `.arch'
+
+   This is a signal that a new assembler is needed if you want to
+   generate BWX insns for your machine.
+   
+   The version of GCC shipped with Red Hat 4.2 (2.7.0.2) has a fault
+   wherein it will silently generate incorrect code. The version shipped
+   with Red Hat 5.0 (2.8.0.1) is not broken, but required an extra
+   -m21164a argument on the command-line. In order to visibly trap
+   2.7.0.2, I now issue DEC's .arch pseudo into the assembly. Relieving
+   the problem of mucking with command-line arguments for 2.8.0.1 is a
+   pleasant side effect.
+   
+   If you've got Red Hat 5.0 installed, you may grab binutils 2.9.1 and
+   be happy. If you've got Red Hat 4.2, bugs make it much harder to
+   upgrade pieces on your own, and you are better off upgrading the
+   entire system.
+   
+   In either case, your problem may be bypassed by not emitting BWX code
+   by default. Do this by using
+  configure alphaev5-unknown-linux-gnulibc1
+
+   if you have RH 4.2, or
+  configure alphaev5-unknown-linux-gnu
+
+   if you have RH 5.0.
+   
+   The following error:
+  Error: macro requires $at register while noat in effect
+
+   also indicates that you should upgrade to a newer version of the
+   assembler, 2.9 or later. If you can not upgrade the assembler, the
+   compiler option "-Wa,-m21164a" may work around this problem.
+     _________________________________________________________________
+   
+  alpha*-dec-osf*
+  
+   If you install a shared libstdc++ and, when you link a non-trivial C++
+   program (for example, gcc/testsuite/g++.other/delete3.C), the linker
+   reports a couple of errors about multiply-defined symbols (for
+   example, nothrow, __throw and terminate(void)), you've probably got a
+   linker bug, for which there's no known fix. The officially recommended
+   work-around is to remove the shared libstdc++.
+   
+   An alternative solution is to arrange that all symbols from libgcc get
+   copied to the shared libstdc++; see detailed solution below.
+   (Surprising as it may seem, this does indeed fix the problem!) _Beware_
+   that this may bring you binary-compatibility problems in the future,
+   if you don't use the same work-around next time you build libstdc++:
+   if programs start to depend on libstdc++ to provide symbols that used
+   to be only in libgcc, you must arrange that libstdc++ keeps providing
+   them, otherwise the programs will have to be relinked.
+   
+   The magic spell is to add -Wl,-all,-lgcc,-none to the definition of
+   macro SHDEPS in libstdc++/config/dec-osf.ml _before_
+   alpha*-dec-osf*/libstdc++/Makefile is created (a [19]patch that does
+   just that is available). If the Makefile already exists, run
+   ./config.status within directory alpha*-dec-osf*/libstdc++ (and
+   alpha*-dec-osf*/ieee/libstdc++, if it also exists). Remove any
+   existing libstdc++.so* from such directories, and run make
+   all-target-libstdc++ in the top-level directory, then make
+   install-target-libstdc++.
+   
+   If you have already removed the build tree, you may just remove
+   libstdc++.so.2.10.0 from the install tree and re-create it with the
+   command gcc -shared -o libstdc++.so.2.10.0
+   -Wl,-all,-lstdc++,-lgcc,-none -lm. If the ieee sub-directory exists,
+   repeat this command in it, with the additional flag -mieee.
+     _________________________________________________________________
+   
+  hppa*-hp-hpux*
+  
+   We _highly_ recommend using gas/binutils-2.8 or newer on all hppa
+   platforms; you may encounter a variety of problems when using the HP
+   assembler.
+   
+   If you wish to use pa-risc 2.0 architecture support, you must use
+   either the HP assembler or a recent [20]snapshot of gas.
+   
+   More specific information to hppa*-hp-hpux* targets follows.
+     _________________________________________________________________
+   
+  hppa*-hp-hpux9
+  
+   The HP assembler has major problems on this platform. We've tried to
+   work around the worst of the problems. However, those workarounds may
+   be causing linker crashes in some circumstances; the workarounds also
+   probably prevent shared libraries from working. Use the GNU assembler
+   to avoid these problems.
+   
+   The configuration scripts for GCC will also trigger a bug in the hpux9
+   shell. To avoid this problem set CONFIG_SHELL to /bin/ksh and SHELL to
+   /bin/ksh in your environment.
+     _________________________________________________________________
+   
+  hppa*-hp-hpux10
+  
+   For hpux10.20, we _highly_ recommend you pick up the latest sed patch
+   PHCO_15468 from HP. HP has two sites which provide patches free of
+   charge:
+     * [21]US, Canada, Asia-Pacific, and Latin-America
+     * [22]Europe
+       
+   The HP assembler on these systems is much better than the hpux9
+   assembler, but still has some problems. Most notably the assembler
+   inserts timestamps into each object file it creates, causing the
+   3-stage comparison test to fail during a `make bootstrap'. You should
+   be able to continue by saying `make all' after getting the failure
+   from `make bootstrap'.
+     _________________________________________________________________
+   
+  i?86-*-linux*
+  
+   You will need binutils-2.9.1.0.15 or newer for exception handling to
+   work.
+   
+   If you receive Signal 11 errors when building on GNU/Linux, then it is
+   possible you have a hardware problem. Further information on this can
+   be found on [23]www.bitwizard.nl.
+     _________________________________________________________________
+   
+  i?86-*-sco3.2v5*
+  
+   If you are building languages other than C, you must follow the
+   instructions about invoking `make bootstrap' because the native
+   OpenServer compiler will build a cc1plus that will not correctly parse
+   many valid C++ programs including those in libgcc.a. _You must do a
+   `make bootstrap' if you are building with the native compiler._
+   
+   Use of the `-march-pentiumpro' flag can result in unrecognized opcodes
+   when using the native assembler. While it's rather rare to see these
+   emitted by GCC yet, errors of the basic form:
+  /usr/tmp/ccaNlqBc.s:22:unknown instruction: fcomip
+  /usr/tmp/ccaNlqBc.s:50:unknown instruction: fucomip
+
+   are symptoms of this problem. You may work around this by not building
+   affected files with that flag or by using the GNU assembler. Users of
+   GNU assembler should see the note below for hazards on doing so.
+   
+   If you choose to configure with --enable-shared you should also
+   specificy --with-gnu-as --disable-multilib even if you are not using
+   the GNU assembler. In doing so you will give up the ability to
+   generate COFF executables as described below. This combination of
+   flags is necessary to suppress negative interactions with multilibing.
+   
+   The native SCO assembler that is provided with the OS at no charge is
+   normally required. If, however, you must be able to use the GNU
+   assembler you may configure this package using the flags
+   --with-gnu-as. You must use a recent version of GNU binutils; version
+   2.9.1 seems to work well. If you select this option, you will be
+   unable to reliably build COFF images. In general, the --with-gnu-as
+   option isn't as well tested as the native assembler.
+   
+   Unlike various prereleases of GCC that used -belf and defaulted to
+   COFF, you must now use the -melf and -mcoff flags to toggle between
+   the two object file formats. ELF is now the default.
+   
+   Look in gcc/config/i386/sco5.h (search for "messy") for additional
+   OpenServer-specific flags.
+   
+   Systems based on OpenServer before 5.0.4 (`uname -X' will tell you
+   what you're running) require TLS597 from ftp.sco.com/TLS for C++
+   constructors and destructors to work right.
+   
+   The system linker in (at least) 5.0.4 and 5.0.5 will sometimes do the
+   wrong thing for a construct that GCC will emit for PIC code. This can
+   be seen as execution testsuite failures when using -fPIC on
+   921215-1.c, 931002-1.c, nestfunc-1.c, and gcov-1.c. For 5.0.5, an
+   updated linker that will cure this problem is available. You must
+   install both [24]ftp://ftp.sco.com/Supplements/rs505a/ and
+   [25]OSS499A.
+   
+   The dynamic linker in OpenServer 5.0.5 (earlier versions may show the
+   same problem) aborts on certain g77-compiled programs. It's
+   particluarly likely to be triggered by building Fortran code with the
+   -fPIC flag. Although it's conceivable that the error could be
+   triggered by other code, only G77-compiled code has been observed to
+   cause this abort. If you are getting core dumps immediately upon
+   execution of your g77 program - and especially if it's compiled with
+   -fPIC - try applying [26]`sco_osr5_g77.patch' to your libf2c and
+   rebuilding GCC. Affected faults, when analyzed in a debugger, will
+   show a stack backtrace with a fault occurring in rtld() and the
+   program running as /usr/lib/ld.so.1. This problem has been reported to
+   SCO engineering and will hopefully be addressed in later releases.
+     _________________________________________________________________
+   
+  i?86-*-udk
+  
+   This target emulates the SCO Universal Development Kit and requires
+   that package be installed. (If it is installed, you will have a
+   /udk/usr/ccs/bin/cc file present.) It's very much like the
+   i?86-*-unixware7* target but is meant to be used when hosting on a
+   system where UDK isn't the default compiler such as OpenServer 5 or
+   Unixware 2. This target will generate binaries that will run on
+   OpenServer, Unixware 2, or Unixware 7, with the same warnings and
+   caveats as the SCO UDK.
+   
+   You can stage1 with either your native compiler or with UDK. If you
+   don't do a full bootstrap when initially building with your native
+   compiler you will have an utterly unusable pile of bits as your
+   reward.
+   
+   This target is a little tricky to build because we have to distinguish
+   it from the native tools (so it gets headers, startups, and libraries
+   from the right place) while making the tools not think we're actually
+   building a cross compiler. The easiest way to do this is with a
+   configure command like this:
+  CC=/udk/usr/ccs/bin/cc _/your/path/to/_gcc/configure --host=i686-pc-udk --tar
+get=i686-pc-udk --exec-prefix=udk-
+
+   _You should substitute 'i686' in the above command with the
+   appropriate processor for your host._
+   
+   You should follow this with a `make bootstrap' then `make install'.
+   You can then access the UDK-targeted GCC tools by adding udk- before
+   the commonly known name. For example, to invoke the C compiler, you
+   would use `udk-gcc'. They will coexist peacefully with any
+   native-target GCC tools you may have installed.
+     _________________________________________________________________
+   
+  *-ibm-aix*
+  
+   AIX Make frequently has problems with GCC makefiles. GNU Make 3.76 or
+   newer is recommended to build on this platform.
+   
+   Some versions of the AIX binder (linker) can fail with a relocation
+   overflow severe error when the -bbigtoc option is used to link
+   GCC-produced object files into an executable that overflows the TOC. A
+   fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND
+   -BBIGTOC) is available from IBM Customer Support and from its
+   [27]service.boulder.ibm.com website as PTF U455193.
+   
+   Binutils does not support AIX 4.3 (at least through release 2.9). GNU
+   as and GNU ld will not work properly and one should not configure GCC
+   to use those GNU utilities. Use the native AIX tools which do
+   interoperate with GCC.
+   
+   AIX 4.3 utilizes a new "large format" archive to support both 32-bit
+   and 64-bit object modules. The routines provided in AIX 4.3.0 and AIX
+   4.3.1 to parse archive libraries did not handle the new format
+   correctly. These routines are used by GCC and result in error messages
+   during linking such as "not a COFF file". The version of the routines
+   shipped with AIX 4.3.1 should work for a 32-bit environment. The -g
+   option of the archive command may be used to create archives of 32-bit
+   objects using the original "small format". A correct version of the
+   routines is shipped with AIX 4.3.2.
+   
+   The initial assembler shipped with AIX 4.3.0 generates incorrect
+   object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUPUT FROM
+   COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer
+   Support and from its [28]service.boulder.ibm.com website as PTF
+   U453956. This fix is incorporated in AIX 4.3.1 and above.
+   
+   The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump
+   core with a segmentation fault when invoked by any version of GCC. A
+   fix for APAR IX87327 will be available from IBM Customer Support.
+     _________________________________________________________________
+   
+  m68k-*-nextstep*
+  
+   You absolutely _must_ use GNU sed and GNU make on this platform.
+   
+   On NEXTSTEP 3.x where x < 3 the build of GCC will abort during stage1
+   with an error message like this:
+  _eh
+  /usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section
+  /usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character
+  valued 95 (_).
+
+   The reason for this is the fact that NeXT's assembler for these
+   versions of the operating system does not support the .section pseudo
+   op that's needed for full C++ exception functionality.
+   
+   As NeXT's assembler is a derived work from GNU as, a free replacement
+   that does can be obtained at
+   [29]ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s
+   .tar.gz.
+   
+   If you try to build the integrated C++ & C++ runtime libraries on this
+   system you will run into trouble with include files. The way to get
+   around this is to use the following sequence. Note you must have write
+   permission to the directory _prefix_ you secified in the configuration
+   preocess of GCC for this sequence to work.
+  cd bld-gcc
+  make all-texinfo all-bison all-byacc all-binutils all-gas all-ld
+  cd gcc
+  make bootstrap
+  make install-headers-tar
+  cd ..
+  make bootstrap3
+     _________________________________________________________________
+   
+  m68k-sun-sunos4.1.1
+  
+   It is reported that you may need the GNU assembler on this platform.
+     _________________________________________________________________
+   
+  mips*-sgi-irix[45]
+  
+   You must use GAS on these platforms, as the native assembler can not
+   handle the code for exception handling support. Either of these
+   messages indicates that you are using the MIPS assembler when instead
+   you should be using GAS:
+  as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
+  .4byte $LECIE1-$LSCIE1
+  as0: Error: ./libgcc2.c, line 1:malformed statement
+
+   or:
+  as0: Error: /src/bld-gcc/gcc/libgcc2.c, line 1:undefined symbol in expression
+  .word $LECIE1-$LSCIE1
+
+   These systems don't have ranlib, which various components in GCC need;
+   you should be able to avoid this problem by installing GNU binutils,
+   which includes a functional ranlib for this system.
+   
+   You may get the following warning on irix4 platforms, it can be safely
+   ignored.
+  warning: foo.o does not have gp tables for all its sections.
+
+   When building GCC, the build process loops rebuilding cc1 over and
+   over again. This happens on mips-sgi-irix5.2, and possibly other
+   platforms.
+   It has been reported that this is a known bug in the make shipped with
+   IRIX 5.2. We recommend you use GNU make instead of the vendor supplied
+   make program; however, you may have success with "smake" on IRIX 5.2
+   if you do not have GNU make available.
+   
+   See [30]http://reality.sgi.com/ariel/freeware for more information
+   about using GCC on IRIX platforms.
+     _________________________________________________________________
+   
+  mips*-sgi-irix6
+  
+   You must _not_ use GAS on irix6 platforms; doing so will only cause
+   problems.
+   
+   These systems don't have ranlib, which various components in GCC need;
+   you should be able to avoid this problem by making a dummy script
+   called ranlib which just exits with zero status and placing it in your
+   path.
+   
+   GCC does not currently support generating O32 ABI binaries in the
+   mips-sgi-irix6 configurations. It used to be possible to create a GCC
+   with O32 ABI only support by configuring it for the mips-sgi-irix5
+   target. See the link below for details.
+   
+   GCC does not correctly pass/return structures which are smaller than
+   16 bytes and which are not 8 bytes. The problem is very involved and
+   difficult to fix. It affects a number of other targets also, but IRIX
+   6 is affected the most, because it is a 64 bit target, and 4 byte
+   structures are common. The exact problem is that structures are being
+   padded at the wrong end, e.g. a 4 byte structure is loaded into the
+   lower 4 bytes of the register when it should be loaded into the upper
+   4 bytes of the register.
+   
+   GCC is consistent with itself, but not consistent with the SGI C
+   compiler [and the SGI supplied runtime libraries], so the only
+   failures that can happen are when there are library functions that
+   take/return such structures. There are very few such library
+   functions. I can only recall seeing two of them: inet_ntoa, and
+   semctl.
+   
+   See [31]http://reality.sgi.com/ariel/freeware for more information
+   about using GCC on IRIX platforms.
+     _________________________________________________________________
+   
+  powerpc-*-linux-gnu*
+  
+   You will need [32]binutils-2.9.4.0.8 or newer for a working GCC. It is
+   strongly recommended to recompile binutils if you initially built it
+   with gcc-2.7.2.x.
+     _________________________________________________________________
+   
+  sparc-sun-solaris2.7
+  
+   Sun patch 107058-01 (1999-01-13) for SPARC Solaris 7 triggers a bug in
+   the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 and
+   later, including all EGCS releases. To avoid this problem, do not
+   install Sun patch 107058-01 until after Sun releases a patch for bug
+   4210064. Sun has a fix for this bug but (as of 1999-06-24) has not yet
+   released it as a patch.
+     _________________________________________________________________
+   
+  sparc-sun-sunos*
+  
+   A bug in the SunOS4 linker will cause it to crash when linking -fPIC
+   compiled objects (and will therefore not allow you to build shared
+   libraries).
+   
+   To fix this problem you can either use the most recent version of
+   binutils or get the latest SunOS4 linker patch (patch ID 100170-10)
+   from Sun's patch site.
+     _________________________________________________________________
+   
+  sparc-unknown-linux-gnulibc1
+  
+   It has been reported that you might need [33]binutils-2.8.1.0.23 for
+   this platform, too.
+     _________________________________________________________________
+   
+  sparc64-*-*
+  
+   GCC version 2.95 is not able to compile code correctly for sparc64
+   targets. Users of the Linux kernel, at least, can use the sparc32
+   program to start up a new shell invocation with an environment that
+   causes configure to recognize (via uname -a) the system as sparc-*-*
+   instead.
+   
+   _all ELF targets (SVR4, Solaris, etc.)_
+   C++ support is significantly better on ELF targets if you use the GNU
+   linker; duplicate copies of inlines, vtables and template
+   instantiations will be discarded automatically.
+     _________________________________________________________________
+   
+  GCC with Windows or OS/2
+  
+   GCC does not currently support Windows, either natively or with the
+   cygwin32 dll. However Mumit Khan has been working on supporting
+   Windows with GCC. You should check out his site if you're interested
+   in Windows support. [34]GNU Win32 related projects
+   
+   GCC does not currently support OS/2. However, Andrew Zabolotny has
+   been working on a generic os/2 port with pgcc. The current code code
+   can be found at [35]http://www.goof.com/pcg/os2/.
+     _________________________________________________________________
+   
+   [36]Return to the GCC Installation page
+   
+   _Last modified on August 15, 1999._
+
+References
+
+   1. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#alpha*-dec-osf*
+   2. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#hppa*-hp-hpux*
+   3. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#hppa*-hp-hpux9
+   4. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#hppa*-hp-hpux10
+   5. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#ix86-*-linux*
+   6. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#ix86-*-sco3.2v5*
+   7. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#ix86-*-udk
+   8. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#*-ibm-aix*
+   9. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#m68k-*-nextstep*
+  10. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#m68k-sun-sunos4.1.1
+  11. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#mips*-sgi-irix[45]
+  12. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#mips*-sgi-irix6
+  13. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#powerpc-*-linux-gnu*
+  14. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#sparc-sun-solaris2.7
+  15. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#sparc-sun-sunos*
+  16. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#sparc-unknown-linux-gnulibc1
+  17. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#sparc64-*-*
+  18. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/specific.html#win+os2
+  19. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/dec-osf-shlibstdc++.patch
+  20. ftp://sourceware.cygnus.com/pub/binutils/snapshots
+  21. http://us-support.external.hp.com/
+  22. http://europe-support.external.hp.com/
+  23. http://www.bitwizard.nl/sig11/
+  24. ftp://ftp.sco.com/Supplements/rs505a/
+  25. ftp://ftp.sco.com/SLS/
+  26. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/sco_osr5_g77.patch
+  27. http://service.boulder.ibm.com/
+  28. http://service.boulder.ibm.com/
+  29. ftp://ftp.next.peak.org/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz
+  30. http://reality.sgi.com/ariel/freeware/
+  31. http://reality.sgi.com/ariel/freeware/
+  32. ftp://ftp.varesearch.com/pub/support/hjl/binutils
+  33. ftp://ftp.yggdrasil.com/private/hjl
+  34. http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
+  35. http://www.goof.com/pcg/os2/
+  36. file://localhost/egcs/omelette/tmp/12663/gcc-2.95.1/install/index.html
diff --git a/gnu/egcs/install/TEST b/gnu/egcs/install/TEST
new file mode 100644
index 00000000000..be13f665991
--- /dev/null
+++ b/gnu/egcs/install/TEST
@@ -0,0 +1,13 @@
+
+                   Installation Instructions: Testing GCC
+                                      
+   The testsuite has been temporarily removed from the gcc distributions
+   until the copyright status of some tests can be determined. It is
+   hoped that the testsuite will be included in the gcc releases again
+   soon.
+   
+   Until the testsuite is included it is impossible to run the testsuite.
+   Sorry.
+     _________________________________________________________________
+   
+   _Last modified on July 15, 1999._
diff --git a/gnu/egcs/install/build.html b/gnu/egcs/install/build.html
new file mode 100644
index 00000000000..55123828006
--- /dev/null
+++ b/gnu/egcs/install/build.html
@@ -0,0 +1,99 @@
+<html>
+<head>
+<title>Installing GCC: Building</title>
+</head>
+<body>
+<h1 align="center">Installing GCC: Building</h1>
+
+<p>Now that GCC is configured, you are ready to build the compiler and
+runtime libraries.
+
+<p>We <b>highly</b> recommend that GCC be built using GNU make; other
+versions may work, then again they might not.  To be safe build with GNU make.
+
+<h2>Building a native compiler</h2>
+
+<p>For a native build issue the command `<code>make bootstrap</code>'.  This 
+will build the entire GCC system, which includes the following steps:
+
+<ul>
+  <li> Build host tools necessary to build the compiler such as texinfo, bison,
+  gperf.<p>
+
+  <li> Build target tools for use by the compiler such as gas, gld, and
+  binutils if they have been properly unpacked into the GCC source tree.<p>
+
+  <li> Perform a 3-stage bootstrap of the compiler.<p>
+
+  <li> Perform a comparison test of the stage2 and stage3 compilers.<p>
+
+  <li> Build runtime libraries using the stage3 compiler from the previous
+  step.
+</ul>
+
+<p>If you are short on disk space you might consider `<code>make 
+bootstrap-lean</code>' instead.  This is identical to `<code>make 
+bootstrap</code>' except that object files from the stage1 and 
+stage2 of the 3-stage bootstrap of the compiler are deleted as 
+soon as they are no longer needed.
+
+<p>If you want to save additional space during the bootstrap and in
+the final installation as well, you can build the compiler binaries
+without debugging information with "make CFLAGS='-O' LIBCFLAGS='-g
+-O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap".  This will save
+roughly 40% of disk space both for the bootstrap and the final installation.
+(Libraries will still contain debugging information.)
+
+<p>If you used the flag <code>--enable-languages=...</code> to restrict
+the compilers to be built, only those you've actually enabled will be
+built. This will of course only build those runtime libraries, for
+which the particular compiler has been built.  Please note,
+that re-defining LANGUAGES when calling `<code>make bootstrap</code>'
+<b>*does not*</b> work anymore!
+
+<h2>Building a cross compiler</h2>
+
+<p> We recommend reading the
+<a href="http://www.objsw.com/CrossGCC/">
+crossgcc FAQ</a> for information about building cross compilers.
+
+<p>When building a cross compiler, it is not generally possible to do a
+3-stage bootstrap of the compiler.  This makes for an interesting problem
+as parts of GCC can only be built with GCC.
+
+<p>To build a cross compiler, we first recommend building and installing a
+native compiler.  You can then use the native GCC compiler to build the
+cross compiler.
+
+<p>Assuming you have already installed a native copy of GCC and configured
+your corss compiler, issue the command "make", which performs the
+following steps:
+<ul>
+  <li> Build host tools necessary to build the compiler such as texinfo, bison,
+  gperf.<p>
+
+  <li> Build target tools for use by the compiler such as gas, gld, and
+  binutils if they have been properly unpacked into the GCC source tree.<p>
+
+  <li> Build the compiler (single stage only).<p>
+
+  <li> Build runtime libraries using the compiler from the previous
+  step.
+</ul>
+
+<p>Note that if an error occurs in any step the make process will exit.
+
+<h2>Building in parallel</h2>
+
+<p> If you have a multiprocessor you can use `<code>make bootstrap
+MAKE="make -j 2" -j 2</code>' instead of just `<code>make bootstrap</code>'
+when building GCC.  You can use a bigger number instead of two if
+you like.  In most cases, it won't help to use a number bigger than
+the number of processors in your machine.
+
+<p>
+<hr>
+<i>Last modified on July 16, 1999.</i>
+
+</body>
+</html>
diff --git a/gnu/egcs/install/configure.html b/gnu/egcs/install/configure.html
new file mode 100644
index 00000000000..f27ab3a6d67
--- /dev/null
+++ b/gnu/egcs/install/configure.html
@@ -0,0 +1,181 @@
+<html>
+<head>
+<title>Installing GCC: Configuration</title>
+</head>
+<body>
+<h1 align="center">Installing GCC: Configuration</h1>
+
+<p>Like most GNU software, GCC must be configured before it can be built.
+This document describes the recommended configuration procedure
+for both native and cross targets.
+
+<p>We use <i>srcdir</i> to refer to the toplevel source directory for
+GCC; we use <i>objdir</i> to refer to the toplevel build/object
+directory.
+
+<p>First, we <b>highly</b> recommend that GCC be built into a
+separate directory than the sources which does <b>not</b> reside
+within the source tree.  This is how we generally build GCC; building
+where <i>srcdir</i> == <i>objdir</i> should still work, but doesn't
+get extensive testing; building where <i>objdir</i> is a subdirectory
+of <i>srcdir</i> is unsupported.
+
+<p>Second, when configuring a native system, either "cc" or "gcc" must be in
+your path or you must set CC in your environment before running configure.
+Otherwise the configuration scripts may fail.
+
+<p>To configure GCC:
+
+<blockquote>
+<tt>
+  <br>% mkdir <i>objdir</i>
+  <br>% cd <i>objdir</i>
+  <br>% <i>srcdir</i>/configure <b>[target]</b> <b>[options]</b>
+</tt>
+</blockquote>
+
+
+<p><b>target specification</b>
+<ul>
+  <li>GCC has code to correctly determine the correct value for
+  <b>target</b> for nearly all native systems.  Therefore, we highly
+  recommend you not provide a configure target when configuring a
+  native compiler.
+
+  <li> <b>target</b> must be specified when configuring a cross compiler;
+  examples of valid targets would be i960-rtems, m68k-coff, sh-elf, etc.
+</ul>
+
+
+<p><b> options specification</b>
+
+<p>Use <b>options</b> to override several configure time options for
+GCC.  A partial list of supported <tt>options</tt>:
+
+<ul>
+  <li> <tt>--prefix=</tt><i>dirname</i> -- Specify the toplevel installation
+  directory.  This is the recommended way to install the tools into a directory
+  other than the default.  The toplevel installation directory defaults to
+  /usr/local.
+
+  <p> We <b>highly</b> recommend against <i>prefix</i> being the same or a
+  subdirectory of <i>objdir</i> or vice versa.
+
+  <p>These additional options control where certain parts of the distribution
+  are installed.  Normally you should not need to use these options.
+  <ul>
+     <li> <tt>--with-local-prefix=</tt><i>dirname</i> -- Specify the installation
+     directory for local include files.  The default is /usr/local.
+
+     <li> <tt>--with-gxx-include-dir=</tt><i>dirname</i> -- Specify the installation
+     directory for g++ header files.  The default is /usr/local/include/g++.
+  </ul>
+
+  <li> <tt>--enable-shared</tt> -- Build shared versions of the C++ runtime
+  libraries if supported <tt>--disable-shared</tt> is the default.
+
+  <li> <tt>--enable-haifa</tt> -- Enable the new Haifa instruction scheduler
+  in the compiler; the new scheduler can significantly improve code on some
+  targets.
+  <br>For EGCS 1.0.x releases <tt>--disable-haifa</tt> is the default on all
+  platforms except the HPPA.
+  <br>For newer releases <tt>--disable-haifa</tt> is the default on all
+  platforms except the alpha, hppa, powerpc, rs6000, SPARC and m32r.
+
+  <li> <tt>--with-gnu-as</tt> -- Specify that the compiler should assume the GNU
+  assembler (aka gas) is available. 
+
+  <li> <tt>--with-gnu-ld</tt> -- Specify that the compiler should assume the GNU
+  linker (aka gld) is available. 
+
+  <li> <tt>--with-stabs</tt> -- Specify that stabs debugging information should be used
+  instead of whatever format the host normally uses.  Normally GCC uses the
+  same debug format as the host system. 
+
+  <li> <tt>--enable-multilib</tt> -- Specify that multiple target libraries
+  should be built to support different target variants, calling conventions,
+  etc.  This is the default. 
+
+  <li> <tt>--enable-threads</tt> -- Specify that the target supports threads.
+  This affects only the Objective-C compiler and runtime library.
+
+  <li> <tt>--enable-threads=</tt><i>lib</i> -- Specify that <i>lib</i> is the
+  thread support library.  This affects only the Objective-C compiler  and
+  runtime library.
+
+  <li> <tt>--with-cpu=</tt><i>cpu</i> -- Specify which cpu variant the
+  compiler should generate code for by default.  This is currently
+  only supported on the some ports, specifically arm, powerpc, and
+  SPARC. If configure does not recognize the model name (e.g. arm700,
+  603e, or ultrasparc) you provide, please check the configure script
+  for a complete list of supported models.
+
+  <li> <tt>--enable-target-optspace</tt> -- Specify that target libraries should  be optimzied for code space instead of code speed.  This is the default for
+  the m32r platform.
+
+  <li> <tt>--enable-cpp</tt> -- Specify that a shell script which emulates
+  traditional cpp functionality should be installed.
+
+  <li> <tt>--enable-cpplib</tt> -- Specify that the functionality of CPP should
+  be integrated into the compiler itself.  This is still under development, but
+  may be useful in limited situations.  This option is never enabled by default.
+
+  <li> <tt>--without-fast-fixincludes</tt> -- Specify that the old, slower
+  method of fixing the system header files should be used. 
+  EGCS 1.1.x and older releases default to the slow version. GCC 2.95 and
+  newer releases will default to the fast version.
+
+  <li> <tt>--enable-version-specific-runtime-libs</tt> -- Specify that runtime
+  libraries should be installed in the compiler specific subdirectory
+  (<tt>${libsubdir}</tt>) rather than the usual places.
+  In addition, libstdc++'s include files will be installed in
+  <tt>${libsubdir}/include/g++</tt> unless you overruled it by using
+  <tt>--with-gxx-include-dir=</tt><i>dirname</i>.
+  Using this option is particularly useful if you intend to use several
+  versions of egcs/gcc in parallel. This is currently supported by <tt>libf2c</tt>
+  and <tt>libstdc++</tt>.
+
+  <li> <tt>--enable-languages=</tt><i>lang1</i><tt>,</tt><i>lang2</i><tt>,...</tt>
+  -- Specify that only a particular subset of compilers and their runtime libraries
+  should be built. For a list of valid values for <i>lang</i><tt>x</tt> you can issue
+  the following command in the <tt>gcc</tt> directory of your GCC source tree:<br>
+  <tt>
+  grep language= */config-lang.in
+  </tt><br>
+  Currently, you can use any of the following: <tt>CHILL</tt>, <tt>c++</tt>,
+  <tt>f77</tt>, <tt>java</tt> and <tt>objc</tt>. Please note, that this switch
+  does not work with EGCS 1.1.2 or older versions of egcs.  It will be supported
+  in GCC 2.95 and newer version.<br>
+  If you do not pass this flag, all languages available in the <tt>gcc</tt> sub-tree
+  will be configured.  Re-defining LANGUAGES when calling <tt>make bootstrap</tt>
+  <b>*does not*</b> work anymore, as those language sub-directories might not have been
+  configured!
+  <li> <tt>--with-dwarf2</tt> -- Specify that the compiler should use DWARF2
+  debugging information as the default.
+
+</ul>
+
+<p>Some options which only apply to building cross compilers:
+<ul>
+  <li> <tt>--with-headers=</tt><i>dir</i> -- Specifies a directory which has
+  target include files.  These include files will be copied into the gcc
+  install directory.  Fixincludes will be run on these files to make them
+  compatible with gcc.
+  <li> <tt>--with-libs=</tt><i>"dir1 dir2 ... dirN"</i> -- Specifies a list of
+  directories which contain the target runtime libraries.  These libraries will
+  be copied into the gcc install directory.
+  <li> <tt>--with-newlib</tt> -- Specifies that "newlib" is being used as the target
+  C library.   This causes __eprintf to be omitted from libgcc.a on the
+  assumption that it will be provided by newlib.
+</ul>
+ 
+<p>Note that each <tt>--enable</tt> option has a corresponding <tt>--disable</tt> option and
+that each <tt>--with</tt> option has a corresponding <tt>--without</tt> option.
+
+
+<p>
+<hr>
+<i>Last modified on July 16, 1999.</i>
+
+</body>
+</html>
diff --git a/gnu/egcs/install/dec-osf-shlibstdc++.patch b/gnu/egcs/install/dec-osf-shlibstdc++.patch
new file mode 100644
index 00000000000..1b2a4acbe3a
--- /dev/null
+++ b/gnu/egcs/install/dec-osf-shlibstdc++.patch
@@ -0,0 +1,27 @@
+Index: libstdc++/ChangeLog
+from  Alexandre Oliva  <oliva@dcc.unicamp.br>
+	
+	* config/dec-osf.ml: Force all of libgcc into libstdc++, to avoid
+	multiply-defined linker errors.
+	
+Index: libstdc++/config/dec-osf.ml
+===================================================================
+RCS file: /egcs/carton/cvsfiles/egcs/libstdc++/config/dec-osf.ml,v
+retrieving revision 1.2
+diff -u -r1.2 dec-osf.ml
+--- libstdc++/config/dec-osf.ml	1998/08/30 21:18:41	1.2
++++ libstdc++/config/dec-osf.ml	1999/07/15 07:40:11
+@@ -3,4 +3,12 @@
+ 
+ LIBS     = $(ARLIB) $(ARLINK) $(SHLIB) $(SHLINK)
+ DEPLIBS  = ../$(SHLIB)
+-SHDEPS   = -lm
++SHDEPS   = -lm -Wl,-all,-lgcc,-none
++# Some testcases in the testsuite required symbols from libgcc, say,
++# __pure_virtual, that would not have been copied into libstdc++
++# without this -Wl switch above.  But __pure_virtual depended on other
++# symbols of libgcc that had been copied to libstdc++.  However,
++# DU4.0d's ld would report such symbols as duplicates, and refuse to
++# link.  Forcing some symbols from libgcc into libstdc++ ensures that
++# we don't get such late undefined symbols, avoiding the bogus
++# multiple-definition errors.
diff --git a/gnu/egcs/install/download.html b/gnu/egcs/install/download.html
new file mode 100644
index 00000000000..a3ed652bb5f
--- /dev/null
+++ b/gnu/egcs/install/download.html
@@ -0,0 +1,38 @@
+<html>
+<head>
+<title>Downloading GCC</title>
+</head>
+<body>
+<h1 align="center">Downloading GCC</h1>
+
+<p>GCC is distributed via FTP tarballs compressed with gzip or bzip2.  It is
+possible to download a full distribution or specific components.
+
+<p>The full distribution includes the C, C++, Objective-C, Fortran, Java,
+and Chill compilers.  The full distribution also includes runtime libraries
+for C++, Objective-C and Fortran.  In the future the GNU compiler testsuites
+will be included in the full distribution.
+
+<p>If you choose to download specific components, you must download the core
+gcc distribution plus any language specific distributions you wish to
+use.  The core distribution includes the C language front-end as well as the
+shared componenets. Each language has a tarball which includes the language
+front-end as well as the language runtime (when appropriate).
+
+<p>Unpack the core distribution as well as any language specific distributions
+in the same directory.
+
+<p>XXX FSF mirror sites
+<p><a href="ftp://egcs.cygnus.com/pub/egcs/releases/index.html">
+FTP download from egcs.cygnus.com (USA California)</a>
+<p><a href="ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html">
+FTP download from go.cygnus.com (USA California -- High speed link
+provided by Stanford)</a>
+<p>GCC releases are available on many <a href="../mirrors.html">FTP mirror sites</a>. If possible, please use one of these.
+
+<p>
+<hr>
+<i>Last modified on July 16, 1999.</i>
+
+</body>
+</html>
diff --git a/gnu/egcs/install/finalinstall.html b/gnu/egcs/install/finalinstall.html
new file mode 100644
index 00000000000..5c11a503213
--- /dev/null
+++ b/gnu/egcs/install/finalinstall.html
@@ -0,0 +1,37 @@
+<html>
+<head>
+<title>Installing GCC: Final installation</title>
+</head>
+<body>
+<h1 align="center">Installing GCC: Final installation</h1>
+
+<p>Now that GCC has been built and tested, you can install it with
+`<code>cd <i>objdir</i>; make install</code>' for a native compiler or
+`<code>cd <i>objdir</i>; make install LANGUAGES="c c++"</code>' for 
+a cross compiler (note installing cross compilers will be easier in the 
+next release!).
+
+
+<p>That step completes the installation of GCC; user level binaries can
+be found in <i>prefix</i>/bin where <i>prefix</i> is the value you specified
+with the --prefix to configure (or /usr/local by default).
+
+<p>If you don't mind, please quickly review the <a
+href="http://egcs.cygnus.com/gcc-2.95/buildstat.html">build status page</a>.
+If your system is not listed, send a note to
+<a href="mailto:gcc@gcc.gnu.org">gcc@gcc.gnu.org</a> indicating
+that you successfully built and installed GCC.
+
+Include the output from running <i>srcdir</i>/config.guess.  (Do not
+send us the config.guess file itself, just the output from running
+it!)
+
+<p>If you find a bug, please report it following our <a
+href="../faq.html#bugreport">bug reporting guidlines</a>.
+
+<p>
+<hr>
+<i>Last modified on July 16, 1999.</i>
+
+</body>
+</html>
diff --git a/gnu/egcs/install/index.html b/gnu/egcs/install/index.html
new file mode 100644
index 00000000000..981ec480695
--- /dev/null
+++ b/gnu/egcs/install/index.html
@@ -0,0 +1,50 @@
+<html>
+<head>
+<title>Installing GCC</title>
+</head>
+<body>
+<h1 align="center">Installing GCC</h1>
+
+<p>The latest version of this document is always available at <a href="
+http://egcs.cygnus.com/install/">http://egcs.cygnus.com/install/</a>.
+
+<p>This document describes the generic installation procedure for GCC as
+well as detailing some target specific installation instructions.
+
+<p>GCC includes several components that previously were separate distributions
+with their own installation instructions.  This document supercedes all 
+package specific installation instructions.  We provide the component specific
+installation information in the source distribution for historical reference
+purposes only.
+
+<p>We recommend you read the entire generic installation instructions as
+well as any target specific installation instructions before you proceed
+to configure, build, test and install GCC.
+
+<p>If something goes wrong in the configure, build, test or install
+procedures, first double check that you followed the generic and target
+specific installation instructions carefully.  Then check the 
+<a href="../faq.html">FAQ</a> to see if your problem is covered before you file
+a bug report.
+
+<p><em>Before</em> starting the build/install procedure <em>please</em> browse
+the <a href="specific.html">host/target specific installation notes</a>.
+
+<p>The installation procedure is broken into five steps.
+
+<ul>
+
+  <li> <a href="download.html">downloading the source</a>
+  <li> <a href="configure.html">configure</a>
+  <li> <a href="build.html">build</a>
+  <li> <a href="test.html">test</a> (optional)
+  <li> <a href="finalinstall.html">install</a>
+
+</ul>
+
+<hr>
+<a href="../index.html">Return to the GCC home page</a>
+<hr>
+<i>Last modified on July 15, 1999.</i>
+</body>
+</html>
diff --git a/gnu/egcs/install/sco_osr5_g77.patch b/gnu/egcs/install/sco_osr5_g77.patch
new file mode 100644
index 00000000000..f41e8c050b8
--- /dev/null
+++ b/gnu/egcs/install/sco_osr5_g77.patch
@@ -0,0 +1,27 @@
+Index: libf2c/libI77/lread.c
+===================================================================
+RCS file: /cvs/egcs/egcs/libf2c/libI77/lread.c,v
+retrieving revision 1.4
+diff -u -p -r1.4 lread.c
+--- lread.c	1999/03/17 08:21:19	1.4
++++ lread.c	1999/07/11 03:42:33
+@@ -70,7 +70,18 @@ un_getc(int x, FILE *f__cf)
+ #endif
+ { return ungetc(x,f__cf); }
+ #else
+-#define un_getc ungetc
++ /* The OpenServer 5.0.5 dynamic linker aborts on g77 programs 
++  * that link against this object.   Simply changing the shape of 
++  * this relocation is enough to circumvent the bug in the dynamic 
++  * linker.
++  */
++#if 0
++ #define un_getc ungetc
++#else
++ typedef int (blah) (int c, FILE *stream);
++ blah *un_getc = ungetc;
++#endif
++
+ #ifdef KR_headers
+  extern int ungetc();
+ #else
diff --git a/gnu/egcs/install/specific.html b/gnu/egcs/install/specific.html
new file mode 100644
index 00000000000..ff2f3f521d4
--- /dev/null
+++ b/gnu/egcs/install/specific.html
@@ -0,0 +1,482 @@
+<html>
+<head>
+<title>Host/Target specific installation notes for GCC</title>
+</head>
+<body>
+
+<h1 align="center">Host/Target specific installation notes for GCC</h1>
+
+<p>Please read this document carefully <i>before</i> installing the GNU Compiler Collection on your machine.</p>
+
+<ul>
+  <li><a href="#alpha*-dec-osf*">alpha*-dec-osf*</a></li>
+  <li><a href="#hppa*-hp-hpux*">hppa*-hp-hpux*</a></li>
+  <li><a href="#hppa*-hp-hpux9">hppa*-hp-hpux9</a></li>
+  <li><a href="#hppa*-hp-hpux10">hppa*-hp-hpux10</a></li>
+  <li><a href="#ix86-*-linux*">i?86-*-linux*</a></li>
+  <li><a href="#ix86-*-sco3.2v5*">i?86-*-sco3.2v5*</a></li>
+  <li><a href="#ix86-*-udk">i?86-*-udk</a></li>
+  <li><a href="#*-ibm-aix*">*-ibm-aix*</a></li>
+  <li><a href="#m68k-*-nextstep*">m68k-*-nextstep*</a></li>
+  <li><a href="#m68k-sun-sunos4.1.1">m68k-sun-sunos4.1.1</a></li>
+  <li><a href="#mips*-sgi-irix[45]">mips*-sgi-irix[45]</a></li>
+  <li><a href="#mips*-sgi-irix6">mips*-sgi-irix6</a></li>
+  <li><a href="#powerpc-*-linux-gnu*">powerpc-*-linux-gnu*</a></li>
+  <li><a href="#sparc-sun-solaris2.7">sparc-sun-solaris2.7</a></li>
+  <li><a href="#sparc-sun-sunos*">sparc-sun-sunos*</a></li>
+  <li><a href="#sparc-unknown-linux-gnulibc1">sparc-unknown-linux-gnulibc1</a></li>
+  <li><a href="#sparc64-*-*">sparc64-*-*</a></li>
+  <li><a href="#win+os2">GCC with Windows or OS/2</a></li>
+</ul>
+
+
+<!-- -------- host/target specific issues start here ---------------- -->
+
+
+<hr>
+<h3><a name="alpha*-dec-linux*">alpha*-dec-linux*</a></h3>
+
+<p>GNU/Linux Alpha EV56 or PCA56 hosts running Red Hat 4.2 or 5.0 may
+see errors of this sort:</p>
+<pre>
+  Error: Unknown pseudo-op:  `.arch'
+</pre>
+<p>This is a signal that a new assembler is needed if you want to generate BWX insns for your machine.</p>
+
+<p>The version of GCC shipped with Red Hat 4.2 (2.7.0.2) has a fault wherein
+it will silently generate incorrect code.  The version shipped with
+Red Hat 5.0 (2.8.0.1) is not broken, but required an extra -m21164a
+argument on the command-line.  In order to visibly trap 2.7.0.2,
+I now issue DEC's .arch pseudo into the assembly.  Relieving the
+problem of mucking with command-line arguments for 2.8.0.1 is a
+pleasant side effect.</p>
+
+<p>If you've got Red Hat 5.0 installed, you may grab binutils 2.9.1
+and be happy.  If you've got Red Hat 4.2, bugs make it much harder
+to upgrade pieces on your own, and you are better off upgrading
+the entire system.</p>
+
+<p>In either case, your problem may be bypassed by not emitting BWX
+code by default.  Do this by using</p>
+<pre>
+  configure alphaev5-unknown-linux-gnulibc1
+</pre>
+<p>if you have RH 4.2, or</p>
+<pre>
+  configure alphaev5-unknown-linux-gnu
+</pre>
+<p>if you have RH 5.0.</p>
+
+<p>The following error:</p>
+<pre>
+  Error: macro requires $at register while noat in effect
+</pre>
+<p>also indicates that you should upgrade to a newer version of
+the assembler, 2.9 or later.  If you can not upgrade the assembler, the
+compiler option "-Wa,-m21164a" may work around this problem.</p>
+
+
+<hr>
+<h3><a name="alpha*-dec-osf*">alpha*-dec-osf*</a></h3>
+
+<p>If you install a shared libstdc++ and, when you link a non-trivial C++
+program (for example, <code>gcc/testsuite/g++.other/delete3.C</code>),
+the linker reports a couple of errors about multiply-defined symbols
+(for example, <code>nothrow</code>, <code>__throw</code> and
+<code>terminate(void)</code>), you've probably got a linker bug, for
+which there's no known fix.  The officially recommended work-around is
+to remove the shared libstdc++.</p>
+
+<p>An alternative solution is to arrange that all symbols from
+<code>libgcc</code> get copied to the shared <code>libstdc++</code>;
+see detailed solution below.  (Surprising as it may seem, this does
+indeed fix the problem!)  <b>Beware</b> that this may bring you
+binary-compatibility problems in the future, if you don't use the same
+work-around next time you build <code>libstdc++</code>: if programs
+start to depend on <code>libstdc++</code> to provide symbols that used
+to be only in <code>libgcc</code>, you must arrange that
+<code>libstdc++</code> keeps providing them, otherwise the programs
+will have to be relinked.</p>
+
+<p>The magic spell is to add <code>-Wl,-all,-lgcc,-none</code> to the
+definition of macro <code>SHDEPS</code> in
+<code>libstdc++/config/dec-osf.ml</code> <b>before</b>
+<code>alpha*-dec-osf*/libstdc++/Makefile</code> is created (a <a
+href="dec-osf-shlibstdc++.patch">patch</a> that does just that is
+available).  If the Makefile already exists, run
+<code>./config.status</code> within directory
+<code>alpha*-dec-osf*/libstdc++</code> (and
+<code>alpha*-dec-osf*/ieee/libstdc++</code>, if it also exists).
+Remove any existing <code>libstdc++.so*</code> from such directories,
+and run <code>make all-target-libstdc++</code> in the top-level
+directory, then <code>make install-target-libstdc++</code>.</p>
+	  
+<p>If you have already removed the build tree, you may just remove
+<code>libstdc++.so.2.10.0</code> from the install tree and re-create
+it with the command <code>gcc -shared -o libstdc++.so.2.10.0
+-Wl,-all,-lstdc++,-lgcc,-none -lm</code>.  If the <code>ieee</code>
+sub-directory exists, repeat this command in it, with the additional
+flag <code>-mieee</code>.</p>
+
+<hr>
+<h3><a name="hppa*-hp-hpux*">hppa*-hp-hpux*</a></h3>
+
+<p>We <b>highly</b> recommend using gas/binutils-2.8 or newer on all hppa
+platforms; you may encounter a variety of problems when using the HP assembler.</p>
+
+<p>If you wish to use pa-risc 2.0 architecture support, you must use either the
+HP assembler or a recent
+<a href="ftp://sourceware.cygnus.com/pub/binutils/snapshots">snapshot of gas</a>.</p>
+
+<p>More specific information to hppa*-hp-hpux* targets follows.</p>
+
+<hr>
+<h3><a name="hppa*-hp-hpux9">hppa*-hp-hpux9</a></h3>
+
+<p>The HP assembler has major problems on this platform.  We've tried to work
+around the worst of the problems.  However, those workarounds may be causing
+linker crashes in some circumstances; the workarounds also probably prevent
+shared libraries from working.  Use the GNU assembler to avoid these problems.</p>
+
+<p>The configuration scripts for GCC will also trigger a bug in the hpux9
+shell.  To avoid this problem set CONFIG_SHELL to /bin/ksh and SHELL to
+/bin/ksh in your environment.</p>
+
+<hr>
+<h3><a name="hppa*-hp-hpux10">hppa*-hp-hpux10</a></h3>
+
+<p>For hpux10.20, we <b>highly</b> recommend you pick up the latest sed
+patch <code>PHCO_15468</code> from HP.  HP has two sites which provide patches free of charge:</p>
+<ul>
+  <li><a href="http://us-support.external.hp.com">US, Canada, Asia-Pacific, and
+Latin-America</a></li>
+  <li><a href="http://europe-support.external.hp.com">Europe</a></li>
+</ul>
+
+<p>The HP assembler on these systems is much better than the hpux9 assembler,
+but still has some problems.  Most notably the assembler inserts timestamps
+into each object file it creates, causing the 3-stage comparison test to fail
+during a `<code>make bootstrap</code>'.  You should be able to continue by 
+saying `<code>make all</code>' after getting the failure from `<code>make 
+bootstrap</code>'.</p>
+
+
+<hr>
+<h3><a name="ix86-*-linux*">i?86-*-linux*</a></h3>
+<p>You will need binutils-2.9.1.0.15 or newer for exception handling to work.</p>
+
+<p>If you receive Signal 11 errors when building on GNU/Linux, then it is
+possible you have a hardware problem.  Further information on this can be
+found on <a href="http://www.bitwizard.nl/sig11/">www.bitwizard.nl.</a></p>
+
+<hr>
+<h3><a name="ix86-*-sco3.2v5*">i?86-*-sco3.2v5*</a></h3>
+
+<p>If you are building languages other than C, you must follow the instructions
+about invoking `<code>make bootstrap</code>' because the native OpenServer
+compiler will build a <code>cc1plus</code> that will not correctly parse many
+valid C++ programs including those in <code>libgcc.a</code>.  <b>You must do a `<code>make bootstrap</code>' if you are building with the native compiler.</b></p>
+
+<p>Use of the `<code>-march-pentiumpro</code>' flag can result in
+unrecognized opcodes when using the native assembler.  While
+it's rather rare to see these emitted by GCC yet, errors of the basic form:</p>
+<pre>
+  /usr/tmp/ccaNlqBc.s:22:unknown instruction: fcomip
+  /usr/tmp/ccaNlqBc.s:50:unknown instruction: fucomip
+</pre>
+<p>are symptoms of this problem.   You may work around this by not
+building affected files with that flag or by using the GNU assembler.   
+Users of GNU assembler should see the note below for hazards on doing so.</p>
+
+<p>If you choose to configure with <code>--enable-shared</code> you should also
+specificy <code>--with-gnu-as --disable-multilib</code> even if you are not
+using the GNU assembler.   In doing so you will give up the ability
+to generate COFF executables as described below.   This combination 
+of flags is necessary to suppress negative interactions with multilibing.</p>
+
+<p>The native SCO assembler that is provided with the OS at no charge
+is normally required.  If, however, you must be able to use the GNU
+assembler you may configure this package using the flags <code>--with-gnu-as</code>.  
+You must use a recent version of GNU binutils; version 2.9.1 seems to work well.
+If you select this option, you will be unable to reliably build COFF
+images.  In general, the <code>--with-gnu-as</code> option isn't as well tested as the native assembler.</p>
+
+<p>Unlike various prereleases of GCC that used <code>-belf</code> and 
+defaulted to COFF, you must now use the <code>-melf</code> and 
+<code>-mcoff</code> flags to toggle between the two object file formats.     
+ELF is now the default.</p>
+
+<p>Look in <code>gcc/config/i386/sco5.h</code> (search for "messy") for additional OpenServer-specific flags.</p>
+
+<p>Systems based on OpenServer before 5.0.4 (`<code>uname -X</code>' will
+tell you what you're running) require TLS597 from ftp.sco.com/TLS for
+C++ constructors and destructors to work right.</p>
+
+<p>The system linker in (at least) 5.0.4 and 5.0.5 will sometimes
+do the wrong thing for a construct that GCC will emit for PIC
+code.  This can be seen as execution testsuite failures when using
+-fPIC on 921215-1.c, 931002-1.c, nestfunc-1.c, and gcov-1.c.
+For 5.0.5, an updated linker that will cure this problem is
+available.  You must install both <a href="ftp://ftp.sco.com/Supplements/rs505a/">
+ftp://ftp.sco.com/Supplements/rs505a/</a> and <a href="ftp://ftp.sco.com/SLS/">
+OSS499A</a>.</p>
+
+<p>The dynamic linker in OpenServer 5.0.5 (earlier versions may show
+the same problem) aborts on certain g77-compiled programs.  It's particluarly
+likely to be triggered by building Fortran code with the <code>-fPIC</code>
+flag.
+Although it's conceivable that the error could be triggered by other
+code, only G77-compiled code has been observed to cause this abort.
+If you are getting core dumps immediately upon execution of your
+g77 program - and especially if it's compiled with -fPIC - try applying
+<a href="sco_osr5_g77.patch"><code>`sco_osr5_g77.patch'</code></a> to your libf2c and 
+rebuilding
+GCC.  Affected faults, when analyzed in a debugger, will show a stack
+backtrace with a fault occurring in <code>rtld()</code> and the program
+running as <code>/usr/lib/ld.so.1</code>.  This problem has been reported to SCO engineering
+and will hopefully be addressed in later releases.</p>
+
+
+<hr>
+<h3><a name="ix86-*-udk">i?86-*-udk</a></h3>
+
+<p>This target emulates the SCO Universal Development Kit and requires that
+package be installed.  (If it is installed, you will have a <code>/udk/usr/ccs/bin/cc </code>file present.)  It's very much like the <code>i?86-*-unixware7*</code> target
+but is meant to be used when hosting on a system where UDK isn't the
+default compiler such as OpenServer 5 or Unixware 2.  This target will
+generate binaries that will run on OpenServer, Unixware 2, or Unixware 7, 
+with the same warnings and caveats as the SCO UDK.</p>
+
+<p>You can stage1 with either your native compiler or with UDK.   If you
+don't do a full bootstrap when initially building with your native compiler
+you will have an utterly unusable pile of bits as your reward.</p>
+
+<p>This target is a little tricky to build because we have to distinguish
+it from the native tools (so it gets headers, startups, and libraries
+from the right place) while making the tools not think we're actually 
+building a cross compiler.   The easiest way to do this is with a configure
+command like this:</p>
+<pre>
+  CC=/udk/usr/ccs/bin/cc <i>/your/path/to/</i>gcc/configure --host=i686-pc-udk --target=i686-pc-udk --exec-prefix=udk-
+</pre>
+<p><i>You should substitute 'i686' in the above command with the appropriate
+processor for your host.</i></p>
+
+<p>You should follow this with a `<code>make bootstrap</code>'  then
+`<code>make install</code>'.  You can then access the UDK-targeted GCC 
+tools by adding <code>udk-</code> before the commonly known name.  For example, to invoke the C compiler, you would use `<code>udk-gcc</code>'.  They will coexist peacefully with any native-target GCC tools you may have installed.</p>
+
+
+<hr>
+<h3><a name="*-ibm-aix*">*-ibm-aix*</a></h3>
+<!-- rs6000-ibm-aix*, powerpc-ibm-aix* -->
+
+<p>AIX Make frequently has problems with GCC makefiles.  GNU Make 3.76 or
+newer is recommended to build on this platform.</p>
+
+<p>Some versions of the AIX binder (linker) can fail with a relocation
+overflow severe error when the -bbigtoc option is used to link
+GCC-produced object files into an executable that overflows the TOC.  A fix
+for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is
+available from IBM Customer Support and from its
+<a href="http://service.boulder.ibm.com/">service.boulder.ibm.com</a>
+website as PTF U455193.</p>
+
+<p>Binutils does not support AIX 4.3 (at least through release 2.9).
+GNU as and GNU ld will not work properly and one should not configure GCC
+to use those GNU utilities.  Use the native AIX tools which do interoperate
+with GCC.</p>
+
+<p>AIX 4.3 utilizes a new &quot;large format&quot; archive to support both
+32-bit and 64-bit object modules.  The routines provided in AIX 4.3.0 and
+AIX 4.3.1 to parse archive libraries did not handle the new format correctly.
+These routines are used by GCC and result in error messages during linking
+such as &quot;not a COFF file&quot;.  The version of the routines shipped
+with AIX 4.3.1 should work for a 32-bit environment.  The <tt>-g</tt> option
+of the archive command may be used to create archives of 32-bit objects
+using the original "small format".  A correct version of the routines is
+shipped with AIX 4.3.2.</p>
+
+<p>The initial assembler shipped with AIX 4.3.0 generates incorrect object
+files.  A fix for APAR IX74254 (64BIT DISASSEMBLED OUPUT FROM COMPILER FAILS
+TO ASSEMBLE/BIND) is available from IBM Customer Support and from its
+<a href="http://service.boulder.ibm.com/">service.boulder.ibm.com</a>
+website as PTF U453956.  This fix is incorporated in AIX 4.3.1 and above.</p>
+
+<p>The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core
+with a segmentation fault when invoked by any version of GCC.  A fix for
+APAR IX87327 will be available from IBM Customer Support.</p>
+
+<hr>
+<h3><a name="m68k-*-nextstep*">m68k-*-nextstep*</a></h3>
+
+<p>You absolutely <b>must</b> use GNU sed and GNU make on this platform.</p>
+
+<p>On NEXTSTEP 3.x where x &lt; 3 the build of GCC will abort during  
+stage1 with an error message like this:</p>
+<pre>
+  _eh
+  /usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section
+  /usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character  
+  valued 95 (_).
+</pre>
+<p>The reason for this is the fact that NeXT's assembler for these  
+versions of the operating system does not support the .section  
+pseudo op that's needed for full C++ exception functionality.</p>
+
+<p>As NeXT's assembler is a derived work from GNU as, a free  
+replacement that does can be obtained at 
+<a href="ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz">ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz</a>.
+</p>
+
+<p>If you try to build the integrated C++ & C++ runtime libraries on this system
+you will run into trouble with include files.  The way to get around this is
+to use the following sequence.  Note you must have write permission to
+the directory <i>prefix</i> you secified in the configuration preocess of GCC for this sequence to work.</p>
+<pre>
+  cd bld-gcc
+  make all-texinfo all-bison all-byacc all-binutils all-gas all-ld
+  cd gcc
+  make bootstrap
+  make install-headers-tar
+  cd ..
+  make bootstrap3
+</pre>
+
+
+<hr>
+<h3><a name="m68k-sun-sunos4.1.1">m68k-sun-sunos4.1.1</a></h3>
+
+<p>It is reported that you may need the GNU assembler on this platform.</p>
+
+<hr>
+<h3><a name="mips*-sgi-irix[45]">mips*-sgi-irix[45]</a></h3>
+
+<p>You must use GAS on these platforms, as the native assembler can not handle the code for exception handling support. Either of these messages indicates that you are using the MIPS assembler when instead you should be using GAS:</p>
+<pre>
+  as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
+  .4byte $LECIE1-$LSCIE1
+  as0: Error: ./libgcc2.c, line 1:malformed statement
+</pre>
+<p>or:</p>
+<pre>
+  as0: Error: /src/bld-gcc/gcc/libgcc2.c, line 1:undefined symbol in expression
+  .word $LECIE1-$LSCIE1
+</pre>
+
+<p>These systems don't have ranlib, which various components in GCC need; you
+should be able to avoid this problem by installing GNU binutils, which includes
+a functional ranlib for this system.</p>
+
+<p>You may get the following warning on irix4 platforms, it can be safely
+ignored.</p>
+<pre>
+  warning: foo.o does not have gp tables for all its sections.
+</pre>
+
+<p>When building GCC, the build process loops rebuilding cc1 over and
+over again.  This happens on mips-sgi-irix5.2, and possibly other platforms.<br>
+It has been reported that this is a known bug in the make shipped with
+IRIX 5.2.  We recommend you use GNU make instead of the vendor supplied
+make program; however, you may have success with "smake" on IRIX 5.2 if
+you do not have GNU make available.</p>
+
+<p>See <a href="http://reality.sgi.com/ariel/freeware/"> 
+http://reality.sgi.com/ariel/freeware</a> for more information about using GCC on IRIX platforms.</p>
+
+<hr>
+<h3><a name="mips*-sgi-irix6">mips*-sgi-irix6</a></h3>
+
+<p>You must <i>not</i> use GAS on irix6 platforms; doing so will only cause problems.</p>
+
+<p>These systems don't have ranlib, which various components in GCC need; you
+should be able to avoid this problem by making a dummy script called ranlib
+which just exits with zero status and placing it in your path.</p>
+
+<p>GCC does not currently support generating O32 ABI binaries in the
+mips-sgi-irix6 configurations.  It used to be possible to create a GCC with O32 ABI only support by configuring it for the mips-sgi-irix5 target.  See the link below for details.</p>
+
+<p>GCC does not correctly pass/return structures which are
+smaller than 16 bytes and which are not 8 bytes. The problem is very
+involved and difficult to fix. It affects a number of other targets also,
+but IRIX 6 is affected the most, because it is a 64 bit target, and 4 byte
+structures are common. The exact problem is that structures are being padded
+at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes
+of the register when it should be loaded into the upper 4 bytes of the
+register. </p>
+
+<p>GCC is consistent with itself, but not consistent with the SGI C compiler
+[and the SGI supplied runtime libraries], so the only failures that can
+happen are when there are library functions that take/return such
+structures. There are very few such library functions. I can only recall
+seeing two of them: inet_ntoa, and semctl. </p>
+
+<p>See <a href="http://reality.sgi.com/ariel/freeware/"> 
+http://reality.sgi.com/ariel/freeware</a> for more information about using GCC on IRIX platforms.</p>
+
+<hr>
+<h3><a name="powerpc-*-linux-gnu*">powerpc-*-linux-gnu*</a></h3>
+
+<p>You will need 
+<a href="ftp://ftp.varesearch.com/pub/support/hjl/binutils">binutils-2.9.4.0.8</a> or newer for a working GCC. It is strongly recommended to recompile binutils
+if you initially built it with gcc-2.7.2.x.</p>
+
+
+<hr>
+<h3><a name="sparc-sun-solaris2.7">sparc-sun-solaris2.7</a></h3>
+
+<p>Sun patch 107058-01 (1999-01-13) for SPARC Solaris 7 triggers a bug in
+the dynamic linker.  This problem (Sun bug 4210064) affects GCC 2.8
+and later, including all EGCS releases.  To avoid this problem, do not
+install Sun patch 107058-01 until after Sun releases a patch for bug
+4210064.  Sun has a fix for this bug but (as of 1999-06-24) has not
+yet released it as a patch.</p>
+
+
+<hr>
+<h3><a name="sparc-sun-sunos*">sparc-sun-sunos*</a></h3>
+
+<p>A bug in the SunOS4 linker will cause it to crash when linking -fPIC compiled
+objects (and will therefore not allow you to build shared libraries).</p>
+
+<p>To fix this problem you can either use the most recent version of binutils or
+get the latest SunOS4 linker patch (patch ID 100170-10) from Sun's patch site.</p>
+
+
+<hr>
+<h3><a name="sparc-unknown-linux-gnulibc1">sparc-unknown-linux-gnulibc1</a></h3>
+
+<p>It has been reported that you might need 
+<a href="ftp://ftp.yggdrasil.com/private/hjl">binutils-2.8.1.0.23</a>
+for this platform, too.</p>
+
+<hr>
+<h3><a name="sparc64-*-*">sparc64-*-*</a></h3>
+
+<p>GCC version 2.95 is not able to compile code correctly for <code>sparc64</code> targets.  Users of the Linux kernel, at least, can use the <code>sparc32</code> program to start up a new shell invocation with an environment that causes <code>configure</code> to recognize (via <code>uname -a</code>) the system as <code>sparc-*-*</code> instead.</p>
+
+<p><b>all ELF targets (SVR4, Solaris, etc.)</b><br>
+C++ support is significantly better on ELF targets if you use the GNU
+linker; duplicate copies of inlines, vtables and template instantiations
+will be discarded automatically.</p>
+
+
+<hr>
+<h3><a name="win+os2"></a>GCC with Windows or OS/2</h3>
+
+<p>GCC does not currently support Windows, either natively or with the
+cygwin32 dll.  However Mumit Khan has been working on supporting Windows
+with GCC.  You should check out his site if you're interested in Windows
+support.
+<a href="http://www.xraylith.wisc.edu/~khan/software/gnu-win32/">GNU Win32 related projects</a></p>
+
+<p>GCC does not currently support OS/2.  However, Andrew Zabolotny has been
+working on a generic os/2 port with pgcc.  The current code code can be found
+at <a href="http://www.goof.com/pcg/os2/">http://www.goof.com/pcg/os2/</a>.</p>
+
+<hr>
+<p><a href="./index.html">Return to the GCC Installation page</a></p>
+<p><i>Last modified on August 15, 1999.</i></p>
+
+</body>
+</html>
diff --git a/gnu/egcs/install/test.html b/gnu/egcs/install/test.html
new file mode 100644
index 00000000000..4113bb3c4d1
--- /dev/null
+++ b/gnu/egcs/install/test.html
@@ -0,0 +1,21 @@
+<html>
+<head>
+<title>Installation Instructions: Testing GCC</title>
+</head>
+
+<body>
+<h1 align="center">Installation Instructions: Testing GCC</h1>
+
+<p>The testsuite has been temporarily removed from the gcc distributions
+until the copyright status of some tests can be determined.  It is hoped
+that the testsuite will be included in the gcc releases again soon.
+
+<p>Until the testsuite is included it is impossible to run the testsuite.
+Sorry.
+
+
+<hr>
+<i>Last modified on July 15, 1999.</i>
+
+</body>
+</html>