aboutsummaryrefslogtreecommitdiff
path: root/INSTALL
diff options
context:
space:
mode:
authorJeff Law <law@gcc.gnu.org>1997-12-05 15:13:17 -0700
committerJeff Law <law@gcc.gnu.org>1997-12-05 15:13:17 -0700
commitf2d765451e5dee21174c6ca6d4174866dbe24e00 (patch)
treed4816ec61b2c9013a45e2d0b1f5cdc7060e5a9ab /INSTALL
parent435bba3a39bd51688b1b6cd15c042a17259d1b8b (diff)
downloadgcc-f2d765451e5dee21174c6ca6d4174866dbe24e00.zip
gcc-f2d765451e5dee21174c6ca6d4174866dbe24e00.tar.gz
gcc-f2d765451e5dee21174c6ca6d4174866dbe24e00.tar.bz2
release branch changes from 11-27 snapshot to egcs-1.0.
From-SVN: r16970
Diffstat (limited to 'INSTALL')
-rw-r--r--INSTALL/BUILD54
-rw-r--r--INSTALL/CONFIGURE108
-rw-r--r--INSTALL/FAQ322
-rw-r--r--INSTALL/FINALINSTALL19
-rw-r--r--INSTALL/INDEX34
-rw-r--r--INSTALL/README14
-rw-r--r--INSTALL/SPECIFIC106
-rw-r--r--INSTALL/TEST28
-rw-r--r--INSTALL/build.html66
-rw-r--r--INSTALL/configure.html122
-rw-r--r--INSTALL/faq.html365
-rw-r--r--INSTALL/finalinstall.html30
-rw-r--r--INSTALL/index.html47
-rw-r--r--INSTALL/specific.html119
-rw-r--r--INSTALL/test.html37
15 files changed, 1471 insertions, 0 deletions
diff --git a/INSTALL/BUILD b/INSTALL/BUILD
new file mode 100644
index 0000000..03779e8
--- /dev/null
+++ b/INSTALL/BUILD
@@ -0,0 +1,54 @@
+Building egcs-1.0
+
+Now that egcs is configured, you are ready to build the compiler and
+runtime libraries.
+
+We highly recommend that egcs be built using gnu-make; other
+versions make 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 egcs compiler 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.
+
+ 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.
+
+Building a cross compiler
+
+We recommend reading the crossgcc FAQ for information about building
+cross compilers.
+"ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1"
+
+For a cross build, issue the command "make cross", 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.
+
+ 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.
+
+
+Last modified on December 2, 1997.
+
diff --git a/INSTALL/CONFIGURE b/INSTALL/CONFIGURE
new file mode 100644
index 0000000..403657f
--- /dev/null
+++ b/INSTALL/CONFIGURE
@@ -0,0 +1,108 @@
+Configuring egcs-1.0
+
+Like most GNU software, egcs must be configured before it can be built.
+This document attempts to describe the recommended configuration procedure
+for both native and cross targets.
+
+We use srcdir to refer to the toplevel source directory for
+egcs; we use objdir to refer to the toplevel build/object
+directory for egcs.
+
+First, we highly recommend that egcs be built into a separate
+directory than the sources. This is how we generally build egcs; building
+where srcdir == objdir should still work, but doesn't get
+extensive testing.
+
+Second, when configuring a native system, either "cc" must be in your
+path or you must set CC in your environment before running configure.
+Otherwise the configuration scripts may fail.
+
+To configure egcs:
+
+ % mkdir objdir
+ % cd objdir
+ % srcdir/configure [target] [options]
+
+
+target specification
+
+ egcs 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
+egcs. 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.
+
+ 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.
+ --disable-haifa is currently the default on all platforms except the HPPA.
+
+ --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 only effects the Objective-C compiler and runtime library.
+
+ --enable-threads=lib -- Specify that lib is the
+ thread support library. This only effects 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
+ RS6000/PowerPC ports.
+
+
+Some options which only apply to building cross compilers:
+
+ --with-headers=dir -- Specifies a directory which has target
+ include files.
+ --with-libs=dirs -- Specifies a list of directories which contain
+ the target runtime libraries.
+ --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 December 2, 1997.
diff --git a/INSTALL/FAQ b/INSTALL/FAQ
new file mode 100644
index 0000000..343243d
--- /dev/null
+++ b/INSTALL/FAQ
@@ -0,0 +1,322 @@
+egcs Frequently Asked Questions
+
+
+How is egcs be different from gcc2?
+
+Six years ago, gcc version 1 had reached a point of stability. For the
+targets it could support, it worked well. It had limitations inherent in
+its design that would be difficult to resolve, so a major effort was made
+and gcc version 2 was the result. When we had gcc2 in a useful state,
+development efforts on gcc1 stopped and we all concentrated on making
+gcc2 better than gcc1 could ever be. This is the kind of step forward
+we want to make with egcs.
+
+In brief, the three biggest differences between egcs and gcc2 are
+these:
+
+
+ More rexamination of basic architectual decisions of
+ gcc and an interest in adding new optimizations;
+
+ working with the groups who have fractured out from gcc2 (like
+ the Linux folks, the Intel optimizations folks, Fortran folks)
+ including more front-ends; and finally
+
+ An open development model (see below) for the development process.
+
+
+These three differences will work together to result in a more
+useful compiler, a more stable compiler, a central compiler that works
+for more people, a compiler that generates better code.
+
+
+There are a lot of exciting compiler optimizations that have come
+out. We want them in gcc. There are a lot of front ends out there for
+gcc for languages like Fortran or Pascal. We want them easily
+installable by users. After six years of working on gcc2, we've come
+to see problems and limitations in the way gcc is architected; it is
+time to address these again.
+
+
+What is an open development model?
+
+With egcs, we are going to try a bazaar style[1] approach to its
+development: We're going to be making snapshots publically available
+to anyone who wants to try them; we're going to welcome anyone to join
+the development mailing list. All of the discussions on the
+development mailing list are available via the web. We're going to be
+making releases with a much higher frequency than they have been made
+in the past: We're shooting for three by the end of 1997.
+
+In addition to weekly snapshots of the egcs development sources, we
+are going to look at making the sources readable from a CVS server by
+anyone. We want to make it so external maintainers of parts of egcs
+are able to commit changes to their part of egcs directly into the
+sources without going through an intermediary.
+
+There have been many potential gcc developers who were not able to
+participate in gcc development in the past. We these people to help in
+any way they can; we ultimately want gcc to be the best compiler in the
+world.
+
+A compiler is a complicated piece of software, there will still be
+strong central maintainers who will reject patches, who will demand
+documentation of implementations, and who will keep the level of
+quality as high as it is today. Code that could use wider testing may
+be intergrated--code that is simply ill-conceived won't be.
+
+egcs is not the first piece of software to use this open development
+process; FreeBSD, the Emacs lisp repository, and Linux are a few
+examples of the bazaar style of development.
+
+With egcs, we will be adding new features and optimizations at a
+rate that has not been done since the creation of gcc2; these additions
+will inevitably have a temporarily destabilizing effect. With the help
+of developers working together with this bazaar style development, the
+resulting stability and quality levels will be better than we've had
+before.
+
+cathedral-vs-bazaar[1]
+ We've been discussing different development models a lot over the
+ past few months. The paper which started all of this introduced two
+ terms: A cathedral development model versus a bazaar
+ development model. The paper is written by Eric S. Raymond, it is
+ called `` http://locke.ccil.org/~esr/writings/cathedral.html" The
+ Cathedral and the Bazaar''. The paper is a useful starting point
+ for discussions.
+
+
+
+bits/libc-lock.h: No such file or directory
+egcs includes a tightly integrated libio and libstdc++ implementation which
+can cause problems on hosts which have libio integrated into their C library
+(most notably Linux).
+
+We believe that we've solved the major technical problems for the most
+common versions of libc found on Linux systems. However, some versions
+of Linux use pre-release versions of glibc2, which egcs has trouble detecting
+and correctly handling.
+
+If you're using one of these pre-release versions of glibc2, you may get
+a message "bits/libc-lock.h: No such file or directory" when building egcs.
+Unfortunately, to fix this problem you will need to update your C library to
+glibc2.0.5c.
+
+Late breaking news: we may have at least a partial solution for these
+problems. So this FAQ entry may no longer be needed.
+
+
+`_IO_stdfile_0_lock' was not declared in this scope
+If you get this error, it means either egcs incorrectly guessed what version
+of libc is installed on your linux system, or you incorrectly specified a
+version of glibc when configuring egcs.
+
+If you did not provide a target name when configuring egcs, then you've
+found a bug which needs to be reported. If you did provide a target name at
+configure time, then you should reconfigure without specifying a target name.
+
+
+Problems building the Fortran compiler
+The Fortran front end can not be built with most vendor compilers; it must
+be built with gcc. As a result, you may get an error if you do not follow
+the install instructions carefully.
+
+In particular, instead of using "make" to build egcs, you should use
+"make bootstrap" if you are building a native compiler or "make cross"
+if you are building a cross compiler.
+
+It has also been reported that the Fortran compiler can not be built
+on Red Hat 4.X linux for the Alpha. Fixing this may require upgrading
+binutils or to Red Hat 5.0; we'll provide more information as it becomes
+available.
+
+
+Problems building on MIPS platforms
+egcs requires the use of GAS on all versions of Irix, except Irix 6 due
+to limitations in older Irix assemblers.
+
+ 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
+
+
+
+ as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression
+ .word $LECIE1-$LSCIE1
+
+
+ For Irix 6, you should use the native assembler as GAS is not supported
+on Irix 6.
+
+
+Problems with exception handling on x86 platforms
+If you are using the GNU assembler (aka gas) on an x86 platform and
+exception handling is not working correctly, then odds are you're using a
+buggy assembler.
+
+We recommend binutils-2.8.0.1.15 or newer.
+"ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz binutils-2.8.0.1.15 source
+ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz binutils-2.8.0.1.15 x86 binary for libc5
+ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz binutils-2.8.0.1.15 x86 binary for glibc2
+Or, you can try a
+ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz binutils snapshot; however, be aware that the binutils snapshot is untested
+and may not work (or even build). Use it at your own risk.
+
+
+Bootstrap comparison failures on HPs
+If you bootstrap the compiler on hpux10 using the HP assembler instead of
+gas, every file will fail the comparison test.
+
+The HP asembler inserts timestamps into object files it creates, causing
+every file to be different. The location of the timestamp varies for each
+object file, so there's no real way to work around this mis-feature.
+
+Odds are your compiler is fine, but there's no way to be certain.
+
+If you use GAS on HPs, then you will not run into this problem because
+GAS never inserts timestamps into object files. For this and various other
+reasons we highly recommend using GAS on HPs.
+
+
+Bootstrap loops rebuilding cc1 over and over
+When building egcs, the build process loops rebuilding cc1 over and
+over again. This happens on mips-sgi-irix5.2, and possibly other platforms.
+
+This is probably a bug somewhere in the egcs Makefile. Until we find and
+fix this bug we recommend you use GNU make instead of vendor supplied make
+programs.
+
+
+Dynamic linker is unable to find GCC libraries
+This problem manifests itself by programs not finding shared libraries
+they depend on when the programs are started. Note this problem often manifests
+itself with failures in the libio/libstdc++ tests after configuring with
+--enable-shared and building egcs.
+
+GCC does not specify a runpath so that the dynamic linker can find dynamic
+libraries at runtime.
+
+The short explaination is that if you always pass a -R option to the
+linker, then your programs become dependent on directories which
+may be NFS mounted, and programs may hang unnecessarily when an
+NFS server goes down.
+
+The problem is not programs that do require the directories; those
+programs are going to hang no matter what you do. The problem is
+programs that do not require the directories.
+
+SunOS effectively always passed a -R option for every -L option;
+this was a bad idea, and so it was removed for Solaris. We should
+not recreate it.
+
+
+Unable to run the testsuite
+If you get a message about unable to find "standard.exp" when trying to
+run the egcs testsuites, then your dejagnu is too old to run the egcs tests.
+You will need to get a newer version of dejagnu; we've made a
+<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz">
+dejagnu snapshot available until a new version of dejagnu can be released.
+
+
+How to build a cross compiler
+ Building cross compilers is a rather complex undertaking because they
+usually need additional software (cross assembler, cross linker, target
+libraries, target include files, etc).
+
+ We recommend reading the <a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1">
+crossgcc FAQ for information about building cross compilers.
+
+ If you have all the pieces available, then `make cross' should build a
+cross compiler. `make LANGUAGES="c c++" install'will install the cross
+compiler.
+
+ Note that if you're trying to build a cross compiler in a tree which
+includes binutils-2.8 in addition to egcs, then you're going to need to
+make a couple minor tweaks so that the cross assembler, linker and
+nm utilities will be found.
+
+binutils-2.8 builds those files as gas.new, ld.new and nm.new; egcs gcc
+looks for them using gas-new, ld-new and nm-new, so you may have to arrange
+for any symlinks which point to &ltfile&gt.new to be changed to &ltfile&gt-new.
+
+
+Snapshots, how, when, why
+ We make snapshots of the egcs sources about once a week; there is no
+predetermined schedule. These snapshots are intended to give everyone
+access to work in progress. Any given snapshot may generate incorrect code
+or even fail to build.
+
+If you plan on downloading and using snapshots, we highly recommend you
+subscribe to the egcs mailing lists. See <a href="index.html#mailinglists">
+mailing lists on the main egcs page for instructions on how to subscribe.
+
+When using the diff files to update from older snapshots to newer snapshots,
+make sure to use "-E" and "-p" arguments to patch so that empty files are
+deleted and full pathnames are provided to patch. If your version of
+patch does not support "-E", you'll need to get a newer version. Also note
+that you may need autoconf, autoheader and various other programs if you use
+diff files to update from one snapshot to the next.
+
+
+How to install both egcs and gcc2
+It may be desirable to install both egcs and gcc2 on the same system. This
+can be done by using different prefix paths at configure time and a few
+symlinks.
+
+Basically, configure the two compilers with different --prefix options,
+then build and install each compiler. Assume you want "gcc" to be the egcs
+compiler and available in /usr/local/bin; also assume that you want "gcc2"
+to be the gcc2 compiler and also available in /usr/local/bin.
+
+The easiest way to do this is to configure egcs with --prefix=/usr/local/egcs
+and gcc2 with --prefix=/usr/local/gcc2. Build and install both compilers.
+Then make a symlink from /usr/local/bin/gcc to /usr/local/egcs/bin/gcc and
+from /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links
+for the "g++", "c++" and "g77" compiler drivers.
+
+
+Problems building Linux kernels
+If you installed a recent binutils/gas snapshot on your Linux system,
+you may not be able to build the kernel because objdump does not understand
+the "-k" switch. The solution for this problem is to remove /usr/bin/encaps.
+
+You may get an internal compiler error compiling process.c in newer
+versions of the Linux kernel on x86 machines. This is a bug in an asm
+statement in process.c, not a bug in egcs. XXX How to fix?!?
+
+You may get errors with the X driver of the form
+_X11TransSocketUNIXConnect: Can't connect: errno = 111
+
+It's a kernel bug. The function sys_iopl in arch/i386/kernel/process.c
+does an illegal hack which used to work but is now broken since GCC optimizes
+more aggressively . The newer 2.1.x kernels already have a fix which should
+also work in 2.0.32.
+
+
+Virtual memory exhausted error
+ This error means your system ran out of memory; this can happen for large
+files, particularly when optimizing. If you're getting this error you should
+consider trying to simplify your files or reducing the optimization level.
+
+Note that using -pedantic or -Wreturn-type can cause an explosion in the
+amount of memory needed for template-heavy C++ code, such as code that uses
+STL. Also note that -Wall includes -Wreturn-type, so if you use -Wall you
+will need to specify -Wno-return-type to turn it off.
+
+
+GCC can not find GAS
+Some configurations like irix4, irix5, hpux* require the use of the GNU
+assembler intead of the system assembler. To ensure that egcs finds the GNU
+assembler, you should configure the GNU assembler with the same --prefix
+option as you used for egcs. Then build & install the GNU assembler.
+
+
+egcs does not work on Red Hat 5.0
+ egcs does not currently work with Red Hat 5.0; we'll update this
+entry with more information as it becomes available.
+
+
+Last modified: December 2, 1997
diff --git a/INSTALL/FINALINSTALL b/INSTALL/FINALINSTALL
new file mode 100644
index 0000000..5d893c5
--- /dev/null
+++ b/INSTALL/FINALINSTALL
@@ -0,0 +1,19 @@
+Final install egcs-1.0
+
+Now that egcs 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 egcs; 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 send egcs@cygnus.com a short mail message
+indicating that you successfully built and installed egcs. Include
+the output from running srcdir/config.guess.
+
+If you find a bug in egcs, please report it to egcs-bugs@cygnus.com
+
+Last modified on December 2, 1997.
diff --git a/INSTALL/INDEX b/INSTALL/INDEX
new file mode 100644
index 0000000..c651389
--- /dev/null
+++ b/INSTALL/INDEX
@@ -0,0 +1,34 @@
+Installing egcs-1.0
+
+This document describes the generic installation procedure for egcs as
+well as detailing some target specific installation instructions for egcs.
+
+egcs 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 egcs.
+
+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 EGCS FAQ
+(FAQ) to see if your problem is covered before you file a bug report.
+
+The installation procedure is broken into four steps.
+
+
+ Configure see CONFIGURE
+ Build see BUILD
+ Test see TEST
+ Final Install see FINALINSTALL
+
+
+Before starting the build/install procedure please browse the
+host/target specific installation notes (SPECIFIC).
+
+Last modified on December 2, 1997.
+
diff --git a/INSTALL/README b/INSTALL/README
new file mode 100644
index 0000000..786ca89
--- /dev/null
+++ b/INSTALL/README
@@ -0,0 +1,14 @@
+This directory contains installation instrutions for egcs-1.00.
+
+We're providing installation instructions in two forms, html and
+plaintext.
+
+index.html is the toplevel install file for html browsers.
+
+INDEX is the toplevel install file in plaintext form.
+
+The most recent HTML installation instructions for egcs can be obtained from
+the egcs web site:
+
+http://www.cygnus.com/egcs/install
+
diff --git a/INSTALL/SPECIFIC b/INSTALL/SPECIFIC
new file mode 100644
index 0000000..386836b
--- /dev/null
+++ b/INSTALL/SPECIFIC
@@ -0,0 +1,106 @@
+Host/Target specific installation notes for egcs-1.0
+
+alpha*-*-*
+No specific installation needs/instructions.
+
+
+i?86-*-linux*
+You will need binutils-2.8.1.0.15 or newer for exception handling to work.
+
+i?86-*-sco3.2v5*
+The SCO assembler is currently required. The GNU assembler is not up
+to the task of switching between ELF and COFF at runtime.
+
+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.
+
+
+
+hppa*-hp-hpux*
+We highly recommend using gas/binutils-2.8 on all hppa platforms; you
+may encounter a variety of problems when using the HP assembler.
+
+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 egcs 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 from HP. HP has two sites which provide patches free of charge.
+
+http://us-support.external.hp.com for US, Canada, Asia-Pacific, and
+Latin-America
+http://europe-support.external.hp.com for Europe
+
+Retrieve patch PHCO_12862.
+
+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".
+
+m68k-*-nextstep*
+You absolutely must use GNU sed and GNU make on this platform.
+
+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
+prefix for this sequence to work.
+
+cd objdir
+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-irix4
+mips*-sgi-irix5
+You must use GAS on these platforms, the native assembler can not handle the
+code for exception handling support on this platform.
+
+These systems don't have ranlib, which various components in egcs 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.
+
+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 egcs 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.
+
+rs6000-ibm-aix*
+powerpc-ibm-aix*
+At least one person as reported problems with older versions of gnu-make on
+this platform. make-3.76 is reported to work correctly.
+
+powerpc-*-linux-gnu*
+You will need binutils-2.8.1.0.17 from ftp://ftp.yggdrasil.com/private/hjl for
+a working egcs. It is strongly recommended to recompile binutils with egcs
+if you initially built it with gcc-2.7.2.*.
+
+
+exception handling
+XXX Linux stuff
+Last modified on December 2, 1997.
diff --git a/INSTALL/TEST b/INSTALL/TEST
new file mode 100644
index 0000000..7492045
--- /dev/null
+++ b/INSTALL/TEST
@@ -0,0 +1,28 @@
+Testing egcs-1.0
+
+Before you install egcs, you might wish to run the egcs testsuite; this
+step is optional and may require you to download additional software.
+
+First, you must have downloaded the egcs testsuites; the full distribution
+contains testsuites. If you downloaded the "core" compiler plus any front
+ends, then you do not have the testsuites. You can download the testsuites
+from the same site where you downloaded the core distribution and language
+front ends.
+
+Second, you must have a new version of dejagnu on your system; dejagnu-1.3
+will not work. We have made a dejagnu snapshot
+ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz
+dejagnu snapshot available in ftp.cygnus.com:/pub/egcs/infrastructure until
+a new version of dejagnu can be released.
+
+Assuming you've got the testsuites unpacked and have installed an appropriate
+dejagnu, you can run the testsuite with "cd objdir; make -k check".
+This may take a long time. Go get some lunch.
+
+The testing process will try to test as many components in the egcs
+distrubution as possible, including the C, C++ and Fortran compiler as
+well as the C++ runtime libraries.
+
+ How to interpret test results XXX.
+
+Last modified on December 2, 1997.
diff --git a/INSTALL/build.html b/INSTALL/build.html
new file mode 100644
index 0000000..750b2c4
--- /dev/null
+++ b/INSTALL/build.html
@@ -0,0 +1,66 @@
+<html>
+<head>
+<title>Building egcs-1.0 </title>
+</head>
+<body bgcolor="white">
+<h1 align="center">Building egcs-1.0</h1>
+
+<p>Now that egcs is configured, you are ready to build the compiler and
+runtime libraries.
+
+<p>We <b>highly</b> recommend that egcs be built using gnu-make; other
+versions make work, then again they might not. To be safe build with gnu-make.
+
+<p><b>Building a native compiler</b>
+<p>For a native build issue the command "make bootstrap". This will build
+the entire egcs compiler 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.<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.<p>
+</ul>
+
+<p>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.
+
+<p><b>Building a cross compiler</b>
+
+<p> We recommend reading the
+<a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1">
+crossgcc FAQ</a> for information about building cross compilers.
+
+<p>For a cross build, issue the command "make cross", 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.<p>
+
+ <li> Build the compiler (single stage only).<p>
+
+ <li> Build runtime libraries using the compiler from the previous
+ step.<p>
+</ul>
+
+<p>Note that if an error occurs in any step the make process will exit.
+
+<p>
+<hr>
+<i>Last modified on December 2, 1997.</i>
+
+</body>
+</html>
diff --git a/INSTALL/configure.html b/INSTALL/configure.html
new file mode 100644
index 0000000..ff26b38
--- /dev/null
+++ b/INSTALL/configure.html
@@ -0,0 +1,122 @@
+<html>
+<head>
+<title>Configuring egcs-1.0 </title>
+</head>
+<body bgcolor="white">
+<h1 align="center">Configuring egcs-1.0</h1>
+
+<p>Like most GNU software, egcs must be configured before it can be built.
+This document attempts to describe the recommended configuration procedure
+for both native and cross targets.
+
+<p>We use <i>srcdir</i> to refer to the toplevel source directory for
+egcs; we use <i>objdir</i> to refer to the toplevel build/object
+directory for egcs.
+
+<p>First, we <b>highly</b> recommend that egcs be built into a separate
+directory than the sources. This is how we generally build egcs; building
+where <i>srcdir</i> == <i>objdir</i> should still work, but doesn't get
+extensive testing.
+
+<p>Second, when configuring a native system, either "cc" 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 egcs:
+
+<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> egcs 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
+egcs. 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.
+
+ <br>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.
+ <tt>--disable-haifa</tt> is currently the default on all platforms except the HPPA.
+
+ <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 only effects 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 only effects 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
+ RS6000/PowerPC ports.
+</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.
+ <li> <tt>--with-libs=</tt><i>dirs</i> -- Specifies a list of directories which contain
+ the target runtime libraries.
+ <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 December 2, 1997.</i>
+
+</body>
+</html>
diff --git a/INSTALL/faq.html b/INSTALL/faq.html
new file mode 100644
index 0000000..cbc82da
--- /dev/null
+++ b/INSTALL/faq.html
@@ -0,0 +1,365 @@
+<html>
+<head>
+<title>egcs Frequently Asked Questions</title>
+</head>
+<body bgcolor="white">
+<h1 align="center">egcs Frequently Asked Questions</h1>
+
+<ol>
+ <li><a href="#gcc-2-diff">How is egcs be different from gcc2?</a>
+ <li><a href="#open-development">What is an open development model?</a>
+ <li><a href="#libc-lock">bits/libc-lock.h: No such file or directory</a>
+ <li><a href="#morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a>
+ <li><a href="#fortran">Problems building the Fortran compiler</a>
+ <li><a href="#mips">Problems building on MIPS platforms</a>
+ <li><a href="#x86eh">Problems with exception handling on x86 platforms</a>
+ <li><a href="#hpcompare">Bootstrap comparison failures on HPs</a>
+ <li><a href="#makebugs">Bootstrap loops rebuilding cc1 over and over</a>
+ <li><a href="#rpath">Dynamic linker is unable to find GCC libraries</a>
+ <li><a href="#rpath">libstdc++/libio tests fail badly with --enable-shared</a>
+ <li><a href="#dejagnu">Unable to run the testsuite</a>
+ <li><a href="#cross">How to build a cross compiler</a>
+ <li><a href="#multiple">How to install both gcc2 and egcs</a>
+ <li><a href="#snapshot">Snapshots, how, when, why</a>
+ <li><a href="#linuxkernel">Problems building Linux kernels</a>
+ <li><a href="#memexhausted">Virtual memory exhausted</a>
+ <li><a href="#gas">GCC can not find GAS</a>
+ <li><a href="#rh5.0">egcs does not work on Red Hat 5.0</a>
+
+</ol>
+
+<hr>
+<h2><a name="gcc-2-diff">How is egcs be different from gcc2?</a></h2>
+
+<p>Six years ago, gcc version 1 had reached a point of stability. For the
+targets it could support, it worked well. It had limitations inherent in
+its design that would be difficult to resolve, so a major effort was made
+and gcc version 2 was the result. When we had gcc2 in a useful state,
+development efforts on gcc1 stopped and we all concentrated on making
+gcc2 better than gcc1 could ever be. This is the kind of step forward
+we want to make with egcs.
+
+<p>In brief, the three biggest differences between egcs and gcc2 are
+these:
+
+<ul>
+ <li>More rexamination of basic architectual decisions of
+ gcc and an interest in adding new optimizations;
+
+ <li>working with the groups who have fractured out from gcc2 (like
+ the Linux folks, the Intel optimizations folks, Fortran folks)
+ including more front-ends; and finally
+
+ <li>An open development model (<a
+ href="#open-development">see below</a>) for the development process.
+</ul>
+
+<p>These three differences will work together to result in a more
+useful compiler, a more stable compiler, a central compiler that works
+for more people, a compiler that generates better code.
+
+
+<p>There are a lot of exciting compiler optimizations that have come
+out. We want them in gcc. There are a lot of front ends out there for
+gcc for languages like Fortran or Pascal. We want them easily
+installable by users. After six years of working on gcc2, we've come
+to see problems and limitations in the way gcc is architected; it is
+time to address these again.
+
+<hr>
+<h2><a name="open-development">What is an open development model?</a></h2>
+
+<p>With egcs, we are going to try a bazaar style<a
+href="#cathedral-vs-bazaar"><b>[1]</b></a> approach to its
+development: We're going to be making snapshots publically available
+to anyone who wants to try them; we're going to welcome anyone to join
+the development mailing list. All of the discussions on the
+development mailing list are available via the web. We're going to be
+making releases with a much higher frequency than they have been made
+in the past: We're shooting for three by the end of 1997.
+
+<p>In addition to weekly snapshots of the egcs development sources, we
+are going to look at making the sources readable from a CVS server by
+anyone. We want to make it so external maintainers of parts of egcs
+are able to commit changes to their part of egcs directly into the
+sources without going through an intermediary.
+
+<p>There have been many potential gcc developers who were not able to
+participate in gcc development in the past. We these people to help in
+any way they can; we ultimately want gcc to be the best compiler in the
+world.
+
+<p>A compiler is a complicated piece of software, there will still be
+strong central maintainers who will reject patches, who will demand
+documentation of implementations, and who will keep the level of
+quality as high as it is today. Code that could use wider testing may
+be intergrated--code that is simply ill-conceived won't be.
+
+<p>egcs is not the first piece of software to use this open development
+process; FreeBSD, the Emacs lisp repository, and Linux are a few
+examples of the bazaar style of development.
+
+<p>With egcs, we will be adding new features and optimizations at a
+rate that has not been done since the creation of gcc2; these additions
+will inevitably have a temporarily destabilizing effect. With the help
+of developers working together with this bazaar style development, the
+resulting stability and quality levels will be better than we've had
+before.
+
+<blockquote>
+<a name="cathedral-vs-bazaar"><b>[1]</b></a>
+ We've been discussing different development models a lot over the
+ past few months. The paper which started all of this introduced two
+ terms: A <b>cathedral</b> development model versus a <b>bazaar</b>
+ development model. The paper is written by Eric S. Raymond, it is
+ called ``<a
+ href="http://locke.ccil.org/~esr/writings/cathedral.html">The
+ Cathedral and the Bazaar</a>''. The paper is a useful starting point
+ for discussions.
+</blockquote>
+
+
+<hr>
+<h2><a name="libc-lock">bits/libc-lock.h: No such file or directory</a></h2>
+<p>egcs includes a tightly integrated libio and libstdc++ implementation which
+can cause problems on hosts which have libio integrated into their C library
+(most notably Linux).
+
+<p>We believe that we've solved the major technical problems for the most
+common versions of libc found on Linux systems. However, some versions
+of Linux use pre-release versions of glibc2, which egcs has trouble detecting
+and correctly handling.
+
+<p>If you're using one of these pre-release versions of glibc2, you may get
+a message "bits/libc-lock.h: No such file or directory" when building egcs.
+Unfortunately, to fix this problem you will need to update your C library to
+glibc2.0.5c.
+
+<p>Late breaking news: we may have at least a partial solution for these
+problems. So this FAQ entry may no longer be needed.
+
+<hr>
+<h2><a name="morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a></h2>
+<p>If you get this error, it means either egcs incorrectly guessed what version
+of libc is installed on your linux system, or you incorrectly specified a
+version of glibc when configuring egcs.
+
+<p>If you did not provide a target name when configuring egcs, then you've
+found a bug which needs to be reported. If you did provide a target name at
+configure time, then you should reconfigure without specifying a target name.
+
+<hr>
+<h2><a name="fortran">Problems building the Fortran compiler</a></h2>
+<p>The Fortran front end can not be built with most vendor compilers; it must
+be built with gcc. As a result, you may get an error if you do not follow
+the install instructions carefully.
+
+<p>In particular, instead of using "make" to build egcs, you should use
+"make bootstrap" if you are building a native compiler or "make cross"
+if you are building a cross compiler.
+
+<p>It has also been reported that the Fortran compiler can not be built
+on Red Hat 4.X linux for the Alpha. Fixing this may require upgrading
+binutils or to Red Hat 5.0; we'll provide more information as it becomes
+available.
+
+<hr>
+<h2><a name="mips">Problems building on MIPS platforms</a></h2>
+<p>egcs requires the use of GAS on all versions of Irix, except Irix 6 due
+to limitations in older Irix assemblers.
+
+<p> Either of these messages indicates that you are using the MIPS assembler
+when instead you should be using GAS.
+
+<pre>
+ as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
+ .4byte $LECIE1-$LSCIE1
+ as0: Error: ./libgcc2.c, line 1:malformed statement
+</pre>
+
+<hr>
+<pre>
+ as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression
+ .word $LECIE1-$LSCIE1
+
+</pre>
+
+
+<p> For Irix 6, you should use the native assembler as GAS is not supported
+on Irix 6.
+
+<hr>
+<h2> <a name="x86eh">Problems with exception handling on x86 platforms</a></h2>
+<p>If you are using the GNU assembler (aka gas) on an x86 platform and
+exception handling is not working correctly, then odds are you're using a
+buggy assembler.
+
+<p>We recommend binutils-2.8.0.1.15 or newer.
+<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz"> binutils-2.8.0.1.15 source</a>
+<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz"> binutils-2.8.0.1.15 x86 binary for libc5</a>
+<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz"> binutils-2.8.0.1.15 x86 binary for glibc2</a>
+Or, you can try a
+<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz"> binutils snapshot</a>; however, be aware that the binutils snapshot is untested
+and may not work (or even build). Use it at your own risk.
+
+<hr>
+<h2> <a name="hpcompare">Bootstrap comparison failures on HPs</a></h2>
+<p>If you bootstrap the compiler on hpux10 using the HP assembler instead of
+gas, every file will fail the comparison test.
+
+<p>The HP asembler inserts timestamps into object files it creates, causing
+every file to be different. The location of the timestamp varies for each
+object file, so there's no real way to work around this mis-feature.
+
+<p>Odds are your compiler is fine, but there's no way to be certain.
+
+<p>If you use GAS on HPs, then you will not run into this problem because
+GAS never inserts timestamps into object files. For this and various other
+reasons we highly recommend using GAS on HPs.
+
+<hr>
+<h2> <a name="makebugs">Bootstrap loops rebuilding cc1 over and over</a></h2>
+<p>When building egcs, the build process loops rebuilding cc1 over and
+over again. This happens on mips-sgi-irix5.2, and possibly other platforms.
+
+<p>This is probably a bug somewhere in the egcs Makefile. Until we find and
+fix this bug we recommend you use GNU make instead of vendor supplied make
+programs.
+
+<hr>
+<h2> <a name="rpath">Dynamic linker is unable to find GCC libraries</a></h2>
+<p>This problem manifests itself by programs not finding shared libraries
+they depend on when the programs are started. Note this problem often manifests
+itself with failures in the libio/libstdc++ tests after configuring with
+--enable-shared and building egcs.
+
+<p>GCC does not specify a runpath so that the dynamic linker can find dynamic
+libraries at runtime.
+
+<p>The short explaination is that if you always pass a -R option to the
+linker, then your programs become dependent on directories which
+may be NFS mounted, and programs may hang unnecessarily when an
+NFS server goes down.
+
+<p>The problem is not programs that do require the directories; those
+programs are going to hang no matter what you do. The problem is
+programs that do not require the directories.
+
+<p>SunOS effectively always passed a -R option for every -L option;
+this was a bad idea, and so it was removed for Solaris. We should
+not recreate it.
+
+<hr>
+<h2> <a name="dejagnu">Unable to run the testsuite</a></h2>
+<p>If you get a message about unable to find "standard.exp" when trying to
+run the egcs testsuites, then your dejagnu is too old to run the egcs tests.
+You will need to get a newer version of dejagnu; we've made a
+<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz">
+dejagnu snapshot</a> available until a new version of dejagnu can be released.
+
+<hr>
+<h2> <a name="cross">How to build a cross compiler</a></h2>
+<p> Building cross compilers is a rather complex undertaking because they
+usually need additional software (cross assembler, cross linker, target
+libraries, target include files, etc).
+
+<p> We recommend reading the <a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1">
+crossgcc FAQ</a> for information about building cross compilers.
+
+<p> If you have all the pieces available, then `make cross' should build a
+cross compiler. `make LANGUAGES="c c++" install'will install the cross
+compiler.
+
+<p> Note that if you're trying to build a cross compiler in a tree which
+includes binutils-2.8 in addition to egcs, then you're going to need to
+make a couple minor tweaks so that the cross assembler, linker and
+nm utilities will be found.
+
+<p>binutils-2.8 builds those files as gas.new, ld.new and nm.new; egcs gcc
+looks for them using gas-new, ld-new and nm-new, so you may have to arrange
+for any symlinks which point to &ltfile&gt.new to be changed to &ltfile&gt-new.
+
+<hr>
+<h2> <a name="snapshot">Snapshots, how, when, why</a></h2>
+<p> We make snapshots of the egcs sources about once a week; there is no
+predetermined schedule. These snapshots are intended to give everyone
+access to work in progress. Any given snapshot may generate incorrect code
+or even fail to build.
+
+<p>If you plan on downloading and using snapshots, we highly recommend you
+subscribe to the egcs mailing lists. See <a href="index.html#mailinglists">
+mailing lists</a> on the main egcs page for instructions on how to subscribe.
+
+<p>When using the diff files to update from older snapshots to newer snapshots,
+make sure to use "-E" and "-p" arguments to patch so that empty files are
+deleted and full pathnames are provided to patch. If your version of
+patch does not support "-E", you'll need to get a newer version. Also note
+that you may need autoconf, autoheader and various other programs if you use
+diff files to update from one snapshot to the next.
+
+<hr>
+<h2> <a name="multiple">How to install both egcs and gcc2</a></h2>
+<p>It may be desirable to install both egcs and gcc2 on the same system. This
+can be done by using different prefix paths at configure time and a few
+symlinks.
+
+<p>Basically, configure the two compilers with different --prefix options,
+then build and install each compiler. Assume you want "gcc" to be the egcs
+compiler and available in /usr/local/bin; also assume that you want "gcc2"
+to be the gcc2 compiler and also available in /usr/local/bin.
+
+<p>The easiest way to do this is to configure egcs with --prefix=/usr/local/egcs
+and gcc2 with --prefix=/usr/local/gcc2. Build and install both compilers.
+Then make a symlink from /usr/local/bin/gcc to /usr/local/egcs/bin/gcc and
+from /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links
+for the "g++", "c++" and "g77" compiler drivers.
+
+<hr>
+<h2> <a name="linuxkernel">Problems building Linux kernels</a></h2>
+<p>If you installed a recent binutils/gas snapshot on your Linux system,
+you may not be able to build the kernel because objdump does not understand
+the "-k" switch. The solution for this problem is to remove /usr/bin/encaps.
+
+<p>You may get an internal compiler error compiling process.c in newer
+versions of the Linux kernel on x86 machines. This is a bug in an asm
+statement in process.c, not a bug in egcs. XXX How to fix?!?
+
+<p>You may get errors with the X driver of the form
+<pre>
+_X11TransSocketUNIXConnect: Can't connect: errno = 111
+</pre>
+
+<p>It's a kernel bug. The function sys_iopl in arch/i386/kernel/process.c
+does an illegal hack which used to work but is now broken since GCC optimizes
+more aggressively . The newer 2.1.x kernels already have a fix which should
+also work in 2.0.32.
+
+<hr>
+<h2> <a name="memexhausted">Virtual memory exhausted error</a></h2>
+<p> This error means your system ran out of memory; this can happen for large
+files, particularly when optimizing. If you're getting this error you should
+consider trying to simplify your files or reducing the optimization level.
+
+<p>Note that using -pedantic or -Wreturn-type can cause an explosion in the
+amount of memory needed for template-heavy C++ code, such as code that uses
+STL. Also note that -Wall includes -Wreturn-type, so if you use -Wall you
+will need to specify -Wno-return-type to turn it off.
+
+<hr>
+<h2> <a name="gas">GCC can not find GAS</a></h2>
+<p>Some configurations like irix4, irix5, hpux* require the use of the GNU
+assembler intead of the system assembler. To ensure that egcs finds the GNU
+assembler, you should configure the GNU assembler with the same --prefix
+option as you used for egcs. Then build & install the GNU assembler.
+
+<hr>
+<h2> <a name="rh5.0">egcs does not work on Red Hat 5.0</a></h2>
+<p> egcs does not currently work with Red Hat 5.0; we'll update this
+entry with more information as it becomes available.
+
+<hr>
+<p><a href="index.html">Return to the egcs home page</a>
+<p><i>Last modified: December 2, 1997</i>
+
+</body>
+</html>
diff --git a/INSTALL/finalinstall.html b/INSTALL/finalinstall.html
new file mode 100644
index 0000000..c7984f1
--- /dev/null
+++ b/INSTALL/finalinstall.html
@@ -0,0 +1,30 @@
+<html>
+<head>
+<title>Final install egcs-1.0 </title>
+</head>
+<body bgcolor="white">
+<h1 align="center">Final install egcs-1.0</h1>
+
+<p>Now that egcs has been built and tested, you can install it with
+`cd <i>objdir</i>; make install' for a native compiler or
+`cd <i>objdir</i>; make install LANGUAGES="c c++"' for a cross compiler
+(note installing cross compilers will be easier in the next release!).
+
+
+<p>That step completes the installation of egcs; 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 send egcs@cygnus.com a short mail message
+indicating that you successfully built and installed egcs. Include
+the output from running <i>srcdir</i>/config.guess.
+
+<p>If you find a bug in egcs, please report it to
+<a href="mailto:egcs-bugs@cygnus.com">egcs-bugs@cygnus.com</a>.
+
+<p>
+<hr>
+<i>Last modified on December 2, 1997.</i>
+
+</body>
+</html>
diff --git a/INSTALL/index.html b/INSTALL/index.html
new file mode 100644
index 0000000..ab4e4e4
--- /dev/null
+++ b/INSTALL/index.html
@@ -0,0 +1,47 @@
+<html>
+<head>
+<title>Installing egcs-1.0 </title>
+</head>
+<body bgcolor="white">
+<h1 align="center">Installing egcs-1.0</h1>
+
+<p>This document describes the generic installation procedure for egcs as
+well as detailing some target specific installation instructions for egcs.
+
+<p>egcs 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 egcs.
+
+<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>The installation procedure is broken into four steps.
+
+<ul>
+
+ <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>
+
+<p>Before starting the build/install procedure <b>please</b> browse the
+<a href="specific.html">host/target specific installation notes</a>.
+
+<hr>
+<a href="../index.html">Return to the egcs home page</a>
+</body>
+</html>
+<hr>
+<i>Last modified on December 2, 1997.</i>
+
diff --git a/INSTALL/specific.html b/INSTALL/specific.html
new file mode 100644
index 0000000..89a81db
--- /dev/null
+++ b/INSTALL/specific.html
@@ -0,0 +1,119 @@
+<html>
+<head>
+<title>Host/Target specific installation notes for egcs-1.0 </title>
+</head>
+<body bgcolor="white">
+<h1 align="center">Host/Target specific installation notes for egcs-1.0</h1>
+
+<p><b>alpha*-*-*</b><br>
+No specific installation needs/instructions.
+
+
+<p><b>i?86-*-linux*</b><br>
+You will need binutils-2.8.1.0.15 or newer for exception handling to work.
+
+<p><b>i?86-*-sco3.2v5*</b><br>
+The SCO assembler is currently required. The GNU assembler is not up
+to the task of switching between ELF and COFF at runtime.
+
+<br>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.
+
+<br>Look in gcc/config/i386/sco5.h (search for "messy") for additional
+OpenServer-specific flags.
+
+
+
+<p><b>hppa*-hp-hpux*</b><br>
+We <b>highly</b> recommend using gas/binutils-2.8 on all hppa platforms; you
+may encounter a variety of problems when using the HP assembler.
+
+XXX How to make sure gcc finds/uses gas.
+
+<p><b>hppa*-hp-hpux9</b><br>
+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.
+
+<br>The configuration scripts for egcs 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><b>hppa*-hp-hpux10</b><br>
+For hpux10.20, we <b>highly</b> recommend you pick up the latest sed
+patch from HP. HP has two sites which provide patches free of charge.
+
+<br><a href="http://us-support.external.hp.com">US, Canada, Asia-Pacific, and
+Latin-America</a>
+<br><a href="http://europe-support.external.hp.com">Europe</a>
+
+<p>Retrieve patch PHCO_12862.
+
+<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 "make bootstrap". You should be able to continue by saying "make all"
+after getting the failure from "make bootstrap".
+
+<p><b>m68k-*-nextstep*</b><br>
+You absolutely must use GNU sed and GNU make on this platform.
+
+<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
+<i>prefix</i> for this sequence to work.
+
+<p>cd <i>objdir</i><br>
+make all-texinfo all-bison all-byacc all-binutils all-gas all-ld<br>
+cd gcc<br>
+make bootstrap<br>
+make install-headers-tar<br>
+cd ..<br>
+make bootstrap3<br>
+
+<p><b>m68k-sun-sunos4.1.1</b><br>
+It is reported that you may need the GNU assembler on this platform.
+
+<p><b>mips*-sgi-irix4</b><br>
+<b>mips*-sgi-irix5</b><br>
+You must use GAS on these platforms, the native assembler can not handle the
+code for exception handling support on this platform.
+
+<p>These systems don't have ranlib, which various components in egcs need; you
+should be able to avoid this problem by installing GNU binutils, which includes
+a functional ranlib for this system.
+
+<p>You may get the following warning on irix4 platforms, it can be safely
+ignored.
+<pre>
+ warning: foo.o does not have gp tables for all its sections.
+</pre>
+
+<p><b>mips*-sgi-irix6</b><br>
+You must not use GAS on irix6 platforms; doing so will only cause problems.
+
+<p>These systems don't have ranlib, which various components in egcs 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><b>rs6000-ibm-aix*</b><br>
+<b>powerpc-ibm-aix*</b><br>
+At least one person as reported problems with older versions of gnu-make on
+this platform. make-3.76 is reported to work correctly.
+
+<p><b>powerpc-*-linux-gnu*</b><br>
+You will need
+<a href="ftp://ftp.yggdrasil.com/private/hjl">binutils-2.8.1.0.17</a> for
+a working egcs. It is strongly recommended to recompile binutils with egcs
+if you initially built it with gcc-2.7.2.*.
+
+<p>
+exception handling
+<p>XXX Linux stuff
+<hr>
+<i>Last modified on December 2, 1997.</i>
+
+</body>
+</html>
diff --git a/INSTALL/test.html b/INSTALL/test.html
new file mode 100644
index 0000000..c77de85
--- /dev/null
+++ b/INSTALL/test.html
@@ -0,0 +1,37 @@
+<html>
+<head>
+<title>Testing egcs-1.0 </title>
+</head>
+<body bgcolor="white">
+<h1 align="center">Testing egcs-1.0</h1>
+
+<p>Before you install egcs, you might wish to run the egcs testsuite; this
+step is optional and may require you to download additional software.
+
+<p>First, you must have downloaded the egcs testsuites; the full distribution
+contains testsuites. If you downloaded the "core" compiler plus any front
+ends, then you do not have the testsuites. You can download the testsuites
+from the same site where you downloaded the core distribution and language
+front ends.
+
+<p>Second, you must have a new version of dejagnu on your system; dejagnu-1.3
+will not work. We have made a
+<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz">
+dejagnu snapshot</a> available in ftp.cygnus.com:/pub/egcs/infrastructure until
+a new version of dejagnu can be released.
+
+<p>Assuming you've got the testsuites unpacked and have installed an appropriate
+dejagnu, you can run the testsuite with "cd <i>objdir</i>; make -k check".
+This may take a long time. Go get some lunch.
+
+<p>The testing process will try to test as many components in the egcs
+distrubution as possible, including the C, C++ and Fortran compiler as
+well as the C++ runtime libraries.
+
+<p> How to interpret test results XXX.
+
+<hr>
+<i>Last modified on December 2, 1997.</i>
+
+</body>
+</html>