Various egcs-1.0.1 related changes.egcs_1_0_1_release

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/egcs_1_00_branch@17282 138bc75d-0d04-0410-961f-82ee72b054a4

21 files changed, 1032 insertions, 659 deletions

diff --git a/ChangeLog b/ChangeLog
index c1e01ea8e2f..415842c98b4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+Fri Jan  2 11:34:38 1998  Jeffrey A Law  (law@cygnus.com)
+
+	* egcs-1.0.1 release.
+
 Wed Dec  3 07:55:59 1997  Jeffrey A Law  (law@cygnus.com)
 
 	* egcs-1.0 release.
diff --git a/INSTALL/BUILD b/INSTALL/BUILD
index 03779e80830..05e0902052e 100644
--- a/INSTALL/BUILD
+++ b/INSTALL/BUILD
@@ -1,54 +1,50 @@
-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.
 
+                            Building egcs-1.0.1
+                                      
+   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 [1]crossgcc FAQ for information about
+   building cross compilers.
+   
+   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 Jan 2, 1998.
+
+References
+
+   1. ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1
diff --git a/INSTALL/CONFIGURE b/INSTALL/CONFIGURE
index 403657fab0c..8bca3494a1e 100644
--- a/INSTALL/CONFIGURE
+++ b/INSTALL/CONFIGURE
@@ -1,108 +1,90 @@
-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.
+                           Configuring egcs-1.0.1
+                                      
+   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 Jan 2, 1998.
diff --git a/INSTALL/FAQ b/INSTALL/FAQ
index 343243ddb17..17ebaa19b0f 100644
--- a/INSTALL/FAQ
+++ b/INSTALL/FAQ
@@ -1,322 +1,506 @@
-egcs Frequently Asked Questions
-
 
+                      egcs Frequently Asked Questions
+                                      
+    1. [1]How is egcs be different from gcc2?
+    2. [2]What is an open development model?
+    3. [3]Releases and Forking
+    4. [4]bits/libc-lock.h: No such file or directory
+    5. [5]`_IO_stdfile_0_lock' was not declared in this scope
+    6. [6]Problems building the Fortran compiler
+    7. [7]Problems building on MIPS platforms
+    8. [8]Problems with exception handling on x86 platforms
+    9. [9]Bootstrap comparison failures on HPs
+   10. [10]Bootstrap loops rebuilding cc1 over and over
+   11. [11]Dynamic linker is unable to find GCC libraries
+   12. [12]libstdc++/libio tests fail badly with --enable-shared
+   13. [13]Unable to run the testsuite
+   14. [14]How to build a cross compiler
+   15. [15]How to install both gcc2 and egcs
+   16. [16]Snapshots, how, when, why
+   17. [17]Problems building Linux kernels
+   18. [18]Virtual memory exhausted
+   19. [19]GCC can not find GAS
+   20. [20]egcs does not work on Red Hat 5.0
+   21. [21]Unable to bootstrap on x86 Solaris2.{5,6}
+   22. [22]EGCS with Windows
+   23. [23]cpp: Usage:... Error
+     [24]EGCS will not build KDE 
+         _____________________________________________________________
+                                        
 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.
-
-
+       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 ([25]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.
-
-
-
+       With egcs, we are going to try a bazaar style[26][1] approach to
+       its development: We're going to be making snapshots publicly
+       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.
+       
+     [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 ``[27]The Cathedral and the Bazaar''. The paper is a useful
+     starting point for discussions.
+         _____________________________________________________________
+                                        
+Releases and Forking?
+
+       Some folks have questioned whether or not making releases is
+       consistent with the goals of the egcs project and whether or not
+       making releases is a fork from gcc2.
+
+The egcs project has several goals, including:
+
+  * Experimenting with a new development model, release process and
+  release packaging,
+
+  * Using the new development model to accelerate development of new
+  features, optimizations, etc for future inclusion in gcc,
+
+  * Providing high quality releases to the public.
+
+An egcs release is a copy of the egcs sources that the developers have
+tested and are believed to be suitable for wider scale use and testing.
+
+Making releases of stable, tested sources is both a goal and a means by
+which we hope to achieve other goals of the egcs project.
+
+The existence of a stable tested release allows egcs to be more thoroughly
+used and tested by a wider audience than is capable of testing snapshots.
+The expanded audience provides developers with critical feedback in a
+timely manner, which is beneficial to GCC as a whole and is consistent with
+the stated goals of egcs.
+
+The gcc maintainers are encouraged to migrate tested fixes and new features
+from egcs into gcc at their discretion.  egcs maintainers are willing to
+assist the gcc maintainers as time permits.  egcs periodically merges in
+changes from gcc into the egcs sources.
+
+What will keep egcs from becoming a fork is cooperation between the
+developers of gcc and egcs.
+
+We don't see this situation as significantly different than other projects
+that make releases based on some version of the gcc sources (Cygnus, g77,
+etc).  All the code is still available for inclusion in gcc at the discretion
+of the gcc maintainers.
+       _____________________________________________________________
+                                        
 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.
-
 
+       This entry should be obsolete, egcs should handle these beta
+       versions of glibc2 correctly.
+       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.
+         _____________________________________________________________
+                                        
 `_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.
-
 
+       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.                                                               
-
 
+       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.
+       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
+       _____________________________________________________________
+                                        
+    as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol i
+n expression
     .word $LECIE1-$LSCIE1
 
-
- For Irix 6, you should use the native assembler as GAS is not supported
-on Irix 6.
-
-
+       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.
-
 
+       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.1.0.15 or newer.
+       [28]binutils-2.8.1.0.15 source
+       [29]binutils-2.8.1.0.15 x86 binary for libc5
+       [30]binutils-2.8.1.0.15 x86 binary for glibc2 Or, you can try a
+       [31]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.
-
 
+       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.
-
 
+       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.
-
 
+       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.
-
 
+       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 [32]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.
-
 
+       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 [33]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>.new
+       to be changed to &ltfile>-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.
-
 
+       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 [34]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.
-
 
+       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?!?
+       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.
+       The reason you must remove /usr/bin/encaps is because it is an
+       obsolete program that was part of older binutils distributions;
+       the Linux kernel's Makefile looks for this program to decide if
+       you have an old or a new binutils. Problems occur if you installed
+       a new binutils but haven't removed encaps, because the Makefile
+       thinks you have the old one. So zap it; trust us, you won't miss
+       it.
+       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
 
-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.
-
-
+       It's a kernel bug. The function sys_iopl in
+       arch/i386/kernel/ioport.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.
-
 
+       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.
-
 
+       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. After the GNU assembler has
+       been installed, proceed with building egcs.
+         _____________________________________________________________
+                                        
 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
+       This entry is obsolete with the release of egcs-1.0.1 which should
+       handle Red Hat 5.0 correctly.
+       egcs-1.0 does not currently work with Red Hat 5.0 on some
+       platforms; we'll update this entry with more information as it
+       becomes available.
+       You may want to try this [35]proposed patch for Red Hat 5.0.
+       Please let us know if you use this patch and whether or not it
+       works.
+         _____________________________________________________________
+                                        
+Unable to bootstrap on x86 Solaris 2.{5,6}
+
+       This entry is obsolete with the release of egcs-1.0.1 which should
+       handle x86 Solaris systems correctly.
+       This patch should fix the problem
+
+Index: t-sol2
+===================================================================
+RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/t-sol2,v
+retrieving revision 1.2
+diff -c -3 -p -r1.2 t-sol2
+*** t-sol2      1997/09/04 23:54:04     1.2
+--- t-sol2      1997/12/04 07:19:07
+*************** crtn.o: $(srcdir)/config/i386/sol2-cn.as
+*** 31,36 ****
+  # to produce a shared library, but since we don't know ahead of time when
+  # we will be doing that, we just always use -fPIC when compiling the
+  # routines in crtstuff.c.
+
+! CRTSTUFF_T_CFLAGS = -fPIC
+  TARGET_LIBGCC2_CFLAGS = -fPIC
+--- 31,40 ----
+  # to produce a shared library, but since we don't know ahead of time when
+  # we will be doing that, we just always use -fPIC when compiling the
+  # routines in crtstuff.c.
++ #
++ # We must also enable optimization to avoid having any code appear after
++ # the call & alignment statement, but before we switch back to the
++ # .text section.
+
+! CRTSTUFF_T_CFLAGS = -fPIC -O2
+  TARGET_LIBGCC2_CFLAGS = -fPIC
+       _____________________________________________________________
+                                        
+EGCS with Windows
+
+       egcs does not currently support windows, either natively or with
+       the cygwin32 dll. However Mumit Khan has been working on
+       supporting Windows with egcs. You should check out his site if
+       you're interested in Windows support. [36]GNU Win32 related
+       projects
+         _____________________________________________________________
+                                        
+cpp: Usage:... Error
+
+       If you get an error like this when building egcs (particularly
+       when building __mulsi3), then you likely have a problem with your
+       environment variables.
+
+cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
+[switches] input output
+       First look for an explicit '.' in either LIBRARY_PATH or
+       GCC_EXEC_PREFIX from your environment. If you do not find an
+       explicit '.', look for an empty pathname in those variables. Note
+       that ':' at either the start or end of these variables is an
+       implicit '.' and will cause problems.
+         _____________________________________________________________
+                                        
+EGCS will not build KDE
+
+       Previous versions of g++ accepted (as a GNU extension)
+       constructor-arguments for the objects in an array of objects
+       dynamically allocated with new. Here's an example of this
+       construct:
+
+    struct S { S(int); }
+    void f() { new S[3](6); }
+       However, this construct is not allowed by the ANSI/ISO Standard,
+       and is no longer accepted by g++.
+       KDE uses such constructs and therefore will not build with egcs;
+       note patches are available to fix KDE.
+         _____________________________________________________________
+                                        
+       [37]Return to the egcs home page
+       Last modified: Jan 2, 1998
+
+References
+
+   1. file://localhost/home/law/INSTALL/faq.html#gcc-2-diff
+   2. file://localhost/home/law/INSTALL/faq.html#open-development
+   3. file://localhost/home/law/INSTALL/faq.html#release-fork
+   4. file://localhost/home/law/INSTALL/faq.html#libc-lock
+   5. file://localhost/home/law/INSTALL/faq.html#morelibc
+   6. file://localhost/home/law/INSTALL/faq.html#fortran
+   7. file://localhost/home/law/INSTALL/faq.html#mips
+   8. file://localhost/home/law/INSTALL/faq.html#x86eh
+   9. file://localhost/home/law/INSTALL/faq.html#hpcompare
+  10. file://localhost/home/law/INSTALL/faq.html#makebugs
+  11. file://localhost/home/law/INSTALL/faq.html#rpath
+  12. file://localhost/home/law/INSTALL/faq.html#rpath
+  13. file://localhost/home/law/INSTALL/faq.html#dejagnu
+  14. file://localhost/home/law/INSTALL/faq.html#cross
+  15. file://localhost/home/law/INSTALL/faq.html#multiple
+  16. file://localhost/home/law/INSTALL/faq.html#snapshot
+  17. file://localhost/home/law/INSTALL/faq.html#linuxkernel
+  18. file://localhost/home/law/INSTALL/faq.html#memexhausted
+  19. file://localhost/home/law/INSTALL/faq.html#gas
+  20. file://localhost/home/law/INSTALL/faq.html#rh5.0
+  21. file://localhost/home/law/INSTALL/faq.html#x86solaris
+  22. file://localhost/home/law/INSTALL/faq.html#windows
+  23. file://localhost/home/law/INSTALL/faq.html#environ
+  24. file://localhost/home/law/INSTALL/faq.html#kde
+  25. file://localhost/home/law/INSTALL/faq.html#open-development
+  26. file://localhost/home/law/INSTALL/faq.html#cathedral-vs-bazaar
+  27. http://locke.ccil.org/~esr/writings/cathedral.html
+  28. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz
+  29. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz
+  30. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz
+  31. ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz
+  32. ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz
+  33. ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1
+  34. file://localhost/home/law/INSTALL/index.html#mailinglists
+  35. http://www.cygnus.com/ml/egcs/1997-Dec/0594.html
+  36. http://www.xraylith.wisc.edu/~khan/software/gnu-win32
+  37. file://localhost/home/law/INSTALL/index.html
diff --git a/INSTALL/FINALINSTALL b/INSTALL/FINALINSTALL
index 5d893c563e0..5508135a2ad 100644
--- a/INSTALL/FINALINSTALL
+++ b/INSTALL/FINALINSTALL
@@ -1,19 +1,26 @@
-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!).
+                          Final install egcs-1.0.1
+                                      
+   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
+   [1]egcs-bugs@cygnus.com.
+   
+     _________________________________________________________________
+                                      
+   Last modified on Jan 2, 1998.
 
+References
 
-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.
+   1. mailto:egcs-bugs@cygnus.com
diff --git a/INSTALL/INDEX b/INSTALL/INDEX
index c651389f3f1..2abbe5979de 100644
--- a/INSTALL/INDEX
+++ b/INSTALL/INDEX
@@ -1,34 +1,46 @@
-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.
 
+                           Installing egcs-1.0.1
+                                      
+   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
+   [1]FAQ to see if your problem is covered before you file a bug report.
+   
+   The installation procedure is broken into four steps.
+     * [2]configure
+     * [3]build
+     * [4]test (optional)
+     * [5]install
+       
+   Before starting the build/install procedure please browse the
+   [6]host/target specific installation notes.
+     _________________________________________________________________
+                                      
+   [7]Return to the egcs home page
+     _________________________________________________________________
+                                      
+   Last modified on Jan 2, 1998.
+
+References
+
+   1. file://localhost/home/law/INSTALL/faq.html
+   2. file://localhost/home/law/INSTALL/configure.html
+   3. file://localhost/home/law/INSTALL/build.html
+   4. file://localhost/home/law/INSTALL/test.html
+   5. file://localhost/home/law/INSTALL/finalinstall.html
+   6. file://localhost/home/law/INSTALL/specific.html
+   7. file://localhost/home/law/index.html
diff --git a/INSTALL/SPECIFIC b/INSTALL/SPECIFIC
index 386836b83d9..5cddc5c7c60 100644
--- a/INSTALL/SPECIFIC
+++ b/INSTALL/SPECIFIC
@@ -1,106 +1,122 @@
-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.
+           Host/Target specific installation notes for egcs-1.0.1
+                                      
+   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.
+   
+   i?86-pc-solaris*
+   You'll need a patch to fix an egcs bug on this platform. [1]x86
+   solaris patch
+   
+   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.
+   [2]US, Canada, Asia-Pacific, and Latin-America
+   [3]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.
+   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 [4]binutils-2.8.1.0.17 for a working egcs. It is
+   strongly recommended to recompile binutils with egcs if you initially
+   built it with gcc-2.7.2.*.
+   
+   sparc-unkonwn-linux-gnulibc1
+   It has been reported that you might need binutils-2.8.1.0.17 for this
+   platform too. [5]binutils-2.8.1.0.17
+   
+   exception handling
+   
+   XXX Linux stuff -k encaps stuff
+     _________________________________________________________________
+                                      
+   Last modified on Jan 2, 1998.
+
+References
+
+   1. http://www.cygnus.com/egcs/faq.html#x86solaris
+   2. http://us-support.external.hp.com/
+   3. http://europe-support.external.hp.com/
+   4. ftp://ftp.yggdrasil.com/private/hjl
+   5. ftp://ftp.yggdrasil.com/private/hjl
diff --git a/INSTALL/TEST b/INSTALL/TEST
index 749204571ca..66b5f3c2f3c 100644
--- a/INSTALL/TEST
+++ b/INSTALL/TEST
@@ -1,28 +1,34 @@
-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.
+                             Testing egcs-1.0.1
+                                      
+   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 [1]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 Jan 2, 1998.
 
-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.
+References
 
-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.
+   1. ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz
diff --git a/INSTALL/build.html b/INSTALL/build.html
index 750b2c4a5f2..f333640496c 100644
--- a/INSTALL/build.html
+++ b/INSTALL/build.html
@@ -1,9 +1,9 @@
 <html>
 <head>
-<title>Building egcs-1.0 </title>
+<title>Building egcs-1.0.1 </title>
 </head>
 <body bgcolor="white">
-<h1 align="center">Building egcs-1.0</h1>
+<h1 align="center">Building egcs-1.0.1</h1>
 
 <p>Now that egcs is configured, you are ready to build the compiler and
 runtime libraries.
@@ -60,7 +60,7 @@ following steps:
 
 <p>
 <hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
 
 </body>
 </html>
diff --git a/INSTALL/configure.html b/INSTALL/configure.html
index ff26b384b9c..2e32d6943da 100644
--- a/INSTALL/configure.html
+++ b/INSTALL/configure.html
@@ -1,9 +1,9 @@
 <html>
 <head>
-<title>Configuring egcs-1.0 </title>
+<title>Configuring egcs-1.0.1 </title>
 </head>
 <body bgcolor="white">
-<h1 align="center">Configuring egcs-1.0</h1>
+<h1 align="center">Configuring egcs-1.0.1</h1>
 
 <p>Like most GNU software, egcs must be configured before it can be built.
 This document attempts to describe the recommended configuration procedure
@@ -116,7 +116,7 @@ that each <tt>--with</tt> option has a corresponding <tt>--without</tt> option.
 
 <p>
 <hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
 
 </body>
 </html>
diff --git a/INSTALL/faq.html b/INSTALL/faq.html
index cbc82dafe12..1a43a77e00d 100644
--- a/INSTALL/faq.html
+++ b/INSTALL/faq.html
@@ -8,6 +8,7 @@
 <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="#release-fork">Releases and Forking</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>
@@ -25,6 +26,10 @@
   <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>
+  <li><a href="#x86solaris">Unable to bootstrap on x86 Solaris2.{5,6}</a>
+  <li><a href="#windows">EGCS with Windows</a>
+  <li><a href="#environ">cpp: Usage:... Error<a>
+  <li><a href="#kde">EGCS will not build KDE<a>
 
 </ol>
 
@@ -71,7 +76,7 @@ time to address these again.
 
 <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
+development:  We're going to be making snapshots publicly 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
@@ -118,9 +123,54 @@ before.
   for discussions.
 </blockquote>
 
+<hr>
+<h2><a name="release-fork">Releases and Forking?</a></h2>
+<p>Some folks have questioned whether or not making releases is consistent
+with the goals of the egcs project and whether or not making releases is
+a fork from gcc2.
+
+<pre>
+The egcs project has several goals, including:
+
+  * Experimenting with a new development model, release process and
+  release packaging,
+
+  * Using the new development model to accelerate development of new
+  features, optimizations, etc for future inclusion in gcc,
+
+  * Providing high quality releases to the public.
+
+An egcs release is a copy of the egcs sources that the developers have
+tested and are believed to be suitable for wider scale use and testing.
+
+Making releases of stable, tested sources is both a goal and a means by
+which we hope to achieve other goals of the egcs project.
+
+The existence of a stable tested release allows egcs to be more thoroughly
+used and tested by a wider audience than is capable of testing snapshots.
+The expanded audience provides developers with critical feedback in a
+timely manner, which is beneficial to GCC as a whole and is consistent with
+the stated goals of egcs.
+
+The gcc maintainers are encouraged to migrate tested fixes and new features
+from egcs into gcc at their discretion.  egcs maintainers are willing to
+assist the gcc maintainers as time permits.  egcs periodically merges in
+changes from gcc into the egcs sources.
+
+What will keep egcs from becoming a fork is cooperation between the
+developers of gcc and egcs.
+
+We don't see this situation as significantly different than other projects
+that make releases based on some version of the gcc sources (Cygnus, g77,
+etc).  All the code is still available for inclusion in gcc at the discretion
+of the gcc maintainers.
+</pre>
 
 <hr>
 <h2><a name="libc-lock">bits/libc-lock.h: No such file or directory</a></h2>
+<p>This entry should be obsolete, egcs should handle these beta versions of
+glibc2 correctly.
+
 <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).
@@ -135,9 +185,6 @@ 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
@@ -194,10 +241,10 @@ on Irix 6.
 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>
+<p>We recommend binutils-2.8.1.0.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.1.0.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.1.0.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.1.0.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.
@@ -254,7 +301,7 @@ not recreate it.
 <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">
+<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz">
 dejagnu snapshot</a> available until a new version of dejagnu can be released.
 
 <hr>
@@ -320,6 +367,13 @@ for the "g++", "c++" and "g77" compiler drivers.
 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>The reason you must remove /usr/bin/encaps is because it is an obsolete
+program that was part of older binutils distributions; the Linux kernel's
+Makefile looks for this program to decide if you have an old or a new
+binutils.  Problems occur if you installed a new binutils but haven't
+removed encaps, because the Makefile thinks you have the old one.  So zap
+it; trust us, you won't miss it.
+
 <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?!?
@@ -329,7 +383,7 @@ statement in process.c, not a bug in egcs.  XXX How to fix?!?
 _X11TransSocketUNIXConnect: Can't connect: errno = 111
 </pre>
 
-<p>It's a kernel bug. The function sys_iopl in arch/i386/kernel/process.c
+<p>It's a kernel bug. The function sys_iopl in arch/i386/kernel/ioport.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.
@@ -350,16 +404,103 @@ will need to specify -Wno-return-type to turn it off.
 <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.
+option as you used for egcs.  Then build & install the GNU assembler.  After
+the GNU assembler has been installed, proceed with building egcs.
 
 <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.
+<p> This entry is obsolete with the release of egcs-1.0.1 which should
+handle Red Hat 5.0 correctly.
+
+<p> egcs-1.0 does not currently work with Red Hat 5.0 on some platforms; we'll
+update this entry with more information as it becomes available.
+
+<p> You may want to try this
+<a href="http://www.cygnus.com/ml/egcs/1997-Dec/0594.html"> proposed patch</a>
+for Red Hat 5.0.  Please let us know if you use this patch and whether or
+not it works.
+
+<hr>
+<h2> <a name="x86solaris">Unable to bootstrap on x86 Solaris 2.{5,6}</a></h2>
+<p> This entry is obsolete with the release of egcs-1.0.1 which should
+handle x86 Solaris systems correctly.
+
+<p>This patch should fix the problem
+
+<pre>
+Index: t-sol2
+===================================================================
+RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/t-sol2,v
+retrieving revision 1.2
+diff -c -3 -p -r1.2 t-sol2
+*** t-sol2	1997/09/04 23:54:04	1.2
+--- t-sol2	1997/12/04 07:19:07
+*************** crtn.o: $(srcdir)/config/i386/sol2-cn.as
+*** 31,36 ****
+  # to produce a shared library, but since we don't know ahead of time when
+  # we will be doing that, we just always use -fPIC when compiling the
+  # routines in crtstuff.c.
+  
+! CRTSTUFF_T_CFLAGS = -fPIC
+  TARGET_LIBGCC2_CFLAGS = -fPIC
+--- 31,40 ----
+  # to produce a shared library, but since we don't know ahead of time when
+  # we will be doing that, we just always use -fPIC when compiling the
+  # routines in crtstuff.c.
++ #
++ # We must also enable optimization to avoid having any code appear after
++ # the call & alignment statement, but before we switch back to the
++ # .text section.
+  
+! CRTSTUFF_T_CFLAGS = -fPIC -O2
+  TARGET_LIBGCC2_CFLAGS = -fPIC
+</pre>
+
+<hr>
+<h2> <a name="windows">EGCS with Windows</a></h2>
+<p>egcs does not currently support windows, either natively or with the
+cygwin32 dll.  However Mumit Khan has been working on supporting Windows
+with egcs.  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>
+
+<hr>
+<h2> <a name="environ">cpp: Usage:... Error</a></h2>
+<p>If you get an error like this when building egcs (particularly when building
+__mulsi3), then you likely have a problem with your environment variables.
+<pre>
+cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
+[switches] input output
+</pre>
+
+<p>First look for an explicit '.' in either LIBRARY_PATH or GCC_EXEC_PREFIX
+from your environment.  If you do not find an explicit '.', look for 
+an empty pathname in those variables.  Note that ':' at either the start
+or end of these variables is an implicit '.' and will cause problems.
+
+<hr>
+<h2> <a name="kde">EGCS will not build KDE</a></h2>
+<p> Previous versions of g++ accepted (as a GNU extension)
+constructor-arguments for the objects in an array of objects
+dynamically allocated with new.  Here's an example of this construct:
+
+<pre>
+    struct S { S(int); }
+    void f() { new S[3](6); }
+</pre>
+
+<p>However, this construct is not allowed by the ANSI/ISO Standard, and
+is no longer accepted by g++.
+
+<p> KDE uses such constructs and therefore will not build with egcs; note
+patches are available to fix KDE.
+
+
+
 
 <hr>
 <p><a href="index.html">Return to the egcs home page</a>
-<p><i>Last modified:  December 2, 1997</i>
+<p><i>Last modified:  Jan 2, 1998</i>
 
 </body>
 </html>
diff --git a/INSTALL/finalinstall.html b/INSTALL/finalinstall.html
index c7984f106a7..d0371a86bf9 100644
--- a/INSTALL/finalinstall.html
+++ b/INSTALL/finalinstall.html
@@ -1,9 +1,9 @@
 <html>
 <head>
-<title>Final install egcs-1.0 </title>
+<title>Final install egcs-1.0.1 </title>
 </head>
 <body bgcolor="white">
-<h1 align="center">Final install egcs-1.0</h1>
+<h1 align="center">Final install egcs-1.0.1</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
@@ -24,7 +24,7 @@ the output from running <i>srcdir</i>/config.guess.
 
 <p>
 <hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
 
 </body>
 </html>
diff --git a/INSTALL/index.html b/INSTALL/index.html
index ab4e4e4cb42..db59254a706 100644
--- a/INSTALL/index.html
+++ b/INSTALL/index.html
@@ -1,9 +1,9 @@
 <html>
 <head>
-<title>Installing egcs-1.0 </title>
+<title>Installing egcs-1.0.1 </title>
 </head>
 <body bgcolor="white">
-<h1 align="center">Installing egcs-1.0</h1>
+<h1 align="center">Installing egcs-1.0.1</h1>
 
 <p>This document describes the generic installation procedure for egcs as
 well as detailing some target specific installation instructions for egcs.
@@ -21,7 +21,7 @@ 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 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.
@@ -43,5 +43,5 @@ a bug report.
 </body>
 </html>
 <hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
 
diff --git a/INSTALL/specific.html b/INSTALL/specific.html
index 89a81db3500..6faa1616080 100644
--- a/INSTALL/specific.html
+++ b/INSTALL/specific.html
@@ -1,9 +1,9 @@
 <html>
 <head>
-<title>Host/Target specific installation notes for egcs-1.0 </title>
+<title>Host/Target specific installation notes for egcs-1.0.1 </title>
 </head>
 <body bgcolor="white">
-<h1 align="center">Host/Target specific installation notes for egcs-1.0</h1>
+<h1 align="center">Host/Target specific installation notes for egcs-1.0.1</h1>
 
 <p><b>alpha*-*-*</b><br>
 No specific installation needs/instructions.
@@ -23,14 +23,16 @@ 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>i?86-pc-solaris*</b><br>
+You'll need a patch to fix an egcs bug on this platform.
+<a href="http://www.cygnus.com/egcs/faq.html#x86solaris"> x86 solaris patch</a>
+
 
 
 <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
@@ -109,11 +111,17 @@ You will need
 a working egcs. It is strongly recommended to recompile binutils with egcs
 if you initially built it with gcc-2.7.2.*.
 
+<p><b>sparc-unkonwn-linux-gnulibc1</b><br>
+It has been reported that you might need binutils-2.8.1.0.17 for this
+platform too.
+<a href="ftp://ftp.yggdrasil.com/private/hjl">binutils-2.8.1.0.17</a>
+
 <p>
 exception handling 
 <p>XXX Linux stuff
+-k encaps stuff
 <hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
 
 </body>
 </html>
diff --git a/INSTALL/test.html b/INSTALL/test.html
index c77de859229..5e2d2fa58d6 100644
--- a/INSTALL/test.html
+++ b/INSTALL/test.html
@@ -1,9 +1,9 @@
 <html>
 <head>
-<title>Testing egcs-1.0 </title>
+<title>Testing egcs-1.0.1 </title>
 </head>
 <body bgcolor="white">
-<h1 align="center">Testing egcs-1.0</h1>
+<h1 align="center">Testing egcs-1.0.1</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.
@@ -16,7 +16,7 @@ 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">
+<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz">
 dejagnu snapshot</a> available in ftp.cygnus.com:/pub/egcs/infrastructure until
 a new version of dejagnu can be released.
 
@@ -31,7 +31,7 @@ well as the C++ runtime libraries.
 <p> How to interpret test results XXX.
 
 <hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
 
 </body>
 </html>
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 46407cb2943..ebaff2d7969 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+Fri Jan  2 23:40:09 1998  Jim Wilson  (wilson@cygnus.com)
+			  Jeffrey A Law  (law@cygnus.com)
+
+	* crtstuff.c (__frame_dummy): New function for irix6.
+	(__do_global_ctors): Call __frame_dummy for irix6.
+	* iris6.h (LINK_SPEC): Hide __frame_dummy too.
+	 
 Wed Dec 24 23:03:42 1997  Jim Wilson  (wilson@cygnus.com)
 
 	* mips.c (mips_expand_epilogue): Emit blockage insn before call to
diff --git a/gcc/config/mips/iris6.h b/gcc/config/mips/iris6.h
index 86746d11e84..109546e60c2 100644
--- a/gcc/config/mips/iris6.h
+++ b/gcc/config/mips/iris6.h
@@ -1,5 +1,5 @@
 /* Definitions of target machine for GNU compiler.  Iris version 6.
-   Copyright (C) 1994, 1995, 1996 Free Software Foundation, Inc.
+   Copyright (C) 1994, 1995, 1996, 1998 Free Software Foundation, Inc.
 
 This file is part of GNU CC.
 
@@ -542,5 +542,5 @@ do {									 \
 %{!static: \
   %{!shared: %{!non_shared: %{!call_shared: -call_shared -no_unresolved}}}} \
 %{rpath} -init __do_global_ctors -fini __do_global_dtors \
-%{shared:-hidden_symbol __do_global_ctors,__do_global_dtors,__EH_FRAME_BEGIN__} \
+%{shared:-hidden_symbol __do_global_ctors,__do_global_dtors,__EH_FRAME_BEGIN__,__frame_dummy} \
 -_SYSTYPE_SVR4 %{mabi=32: -32}%{mabi=n32: -n32}%{mabi=64: -64} %{!mabi*: -n32}"
diff --git a/gcc/crtstuff.c b/gcc/crtstuff.c
index 7e3c3edb25a..ef683a199d9 100644
--- a/gcc/crtstuff.c
+++ b/gcc/crtstuff.c
@@ -1,6 +1,6 @@
 /* Specialized bits of code needed to support construction and
    destruction of file-scope objects in C++ code.
-   Copyright (C) 1991, 1994, 1995, 1996 Free Software Foundation, Inc.
+   Copyright (C) 1991, 1994, 1995, 1996, 1997 Free Software Foundation, Inc.
    Contributed by Ron Guilmette (rfg@monkeys.com).
 
 This file is part of GNU CC.
@@ -257,6 +257,18 @@ __do_global_dtors ()
   __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
+
+#ifdef EH_FRAME_SECTION_ASM_OP
+/* Define a function here to call __register_frame.  crtend.o is linked in
+   after libgcc.a, and hence can't call libgcc.a functions directly.  That
+   can lead to unresolved function references.  */
+void
+__frame_dummy ()
+{
+  static struct object object;
+  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+}
+#endif
 #endif
 
 #endif /* defined(INIT_SECTION_ASM_OP) */
@@ -387,15 +399,13 @@ __do_global_ctors_aux ()	/* prologue goes in .text section */
 /* This case is used by the Irix 6 port, which supports named sections but
    not an SVR4-style .init section.  __do_global_ctors can be non-static
    in this case because we protect it with -hidden_symbol.  */
-extern char __EH_FRAME_BEGIN__[];
 static func_ptr __CTOR_END__[];
 void
 __do_global_ctors ()
 {
   func_ptr *p;
 #ifdef EH_FRAME_SECTION_ASM_OP
-  static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+  __frame_dummy ();
 #endif
   for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
     (*p) ();
diff --git a/gcc/gcc.1 b/gcc/gcc.1
index 4b6ccd3a2e4..10422c2ea03 100644
--- a/gcc/gcc.1
+++ b/gcc/gcc.1
@@ -20,10 +20,10 @@
 .if n .sp
 .if t .sp 0.4
 ..
-.Id $Id: gcc.1,v 1.1.1.1 1997/08/11 15:57:07 law Exp $
+.Id $Id: gcc.1,v 1.1.1.1.2.1 1997/12/03 08:07:52 law Exp $
 .TH GCC 1 "\*(Dt" "GNU Tools" "GNU Tools"
 .SH NAME
-gcc, g++ \- GNU project C and C++ Compiler (egcs-1.0)
+gcc, g++ \- GNU project C and C++ Compiler (egcs-1.0.1)
 .SH SYNOPSIS
 .B gcc
 .RI "[ " option " | " filename " ].\|.\|."
diff --git a/gcc/gcc.texi b/gcc/gcc.texi
index 99887cdd661..5072b86e1ef 100644
--- a/gcc/gcc.texi
+++ b/gcc/gcc.texi
@@ -148,7 +148,7 @@ original English.
 @sp 1
 @c The version number appears twice more in this file.
 
-@center for egcs-1.0
+@center for egcs-1.0.1
 @page
 @vskip 0pt plus 1filll
 Copyright @copyright{} 1988, 89, 92, 93, 94, 95, 96 Free Software Foundation, Inc.
diff --git a/gcc/version.c b/gcc/version.c
index f04d3c87512..b91ba861425 100644
--- a/gcc/version.c
+++ b/gcc/version.c
@@ -1 +1 @@
-char *version_string = "egcs-2.90.22 971220 (egcs-1.01 beta)";
+char *version_string = "egcs-2.90.23 980102 (egcs-1.0.1 release)";