diff --git a/INSTALL/BUILD b/INSTALL/BUILD
deleted file mode 100644
index 03779e80830..00000000000
--- a/INSTALL/BUILD
+++ /dev/null
@@ -1,54 +0,0 @@
-Building egcs-1.0
-
-Now that egcs is configured, you are ready to build the compiler and
-runtime libraries.
-
-We highly recommend that egcs be built using gnu-make; other
-versions make work, then again they might not. To be safe build with gnu-make.
-
-Building a native compiler
-For a native build issue the command "make bootstrap". This will build
-the entire egcs compiler system, which includes the following steps:
-
-
- Build host tools necessary to build the compiler such as texinfo, bison,
- gperf.
-
- Build target tools for use by the compiler such as gas, gld, and binutils.
-
- Perform a 3-stage bootstrap of the compiler.
-
- Perform a comparison test of the stage2 and stage3 compilers.
-
- Build runtime libraries using the stage3 compiler from the previous step.
-
-
-If you are short on disk space you might consider "make bootstrap-lean"
-instead. This is identical to "make bootstrap" except that object files
-from the stage1 and stage2 of the 3-stage bootstrap of the compiler are
-deleted as soon as they are no longer needed.
-
-Building a cross compiler
-
-We recommend reading the crossgcc FAQ for information about building
-cross compilers.
-"ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1"
-
-For a cross build, issue the command "make cross", which performs the
-following steps:
-
- Build host tools necessary to build the compiler such as texinfo, bison,
- gperf.
-
- Build target tools for use by the compiler such as gas, gld, and binutils.
-
- Build the compiler (single stage only).
-
- Build runtime libraries using the compiler from the previous step.
-
-
-Note that if an error occurs in any step the make process will exit.
-
-
-Last modified on December 2, 1997.
-
diff --git a/INSTALL/CONFIGURE b/INSTALL/CONFIGURE
deleted file mode 100644
index 403657fab0c..00000000000
--- a/INSTALL/CONFIGURE
+++ /dev/null
@@ -1,108 +0,0 @@
-Configuring egcs-1.0
-
-Like most GNU software, egcs must be configured before it can be built.
-This document attempts to describe the recommended configuration procedure
-for both native and cross targets.
-
-We use srcdir to refer to the toplevel source directory for
-egcs; we use objdir to refer to the toplevel build/object
-directory for egcs.
-
-First, we highly recommend that egcs be built into a separate
-directory than the sources. This is how we generally build egcs; building
-where srcdir == objdir should still work, but doesn't get
-extensive testing.
-
-Second, when configuring a native system, either "cc" must be in your
-path or you must set CC in your environment before running configure.
-Otherwise the configuration scripts may fail.
-
-To configure egcs:
-
- % mkdir objdir
- % cd objdir
- % srcdir/configure [target] [options]
-
-
-target specification
-
- egcs has code to correctly determine the correct value for
- target for nearly all native systems. Therefore, we highly
- recommend you not provide a configure target when configuring a
- native compiler.
-
- target must be specified when configuring a cross compiler;
- examples of valid targets would be i960-rtems, m68k-coff, sh-elf, etc.
-
-
-options specification
-
-Use options to override several configure time options for
-egcs. A partial list of supported options:
-
-
- --prefix=dirname -- Specify the toplevel installation
- directory. This is the recommended way to install the tools into a directory
- other than the default. The toplevel installation directory defaults to
- /usr/local.
-
- These additional options control where certain parts of the distribution
- are installed. Normally you should not need to use these options.
-
- --with-local-prefix=dirname -- Specify the installation
- directory for local include files. The default is /usr/local.
-
- --with-gxx-include-dir=dirname -- Specify the installation
- directory for g++ header files. The default is /usr/local/include/g++.
-
-
- --enable-shared -- Build shared versions of the C++ runtime
- libraries if supported --disable-shared is the default.
-
- --enable-haifa -- Enable the new Haifa instruction scheduler in the
- compiler; the new scheduler can significantly improve code on some targets.
- --disable-haifa is currently the default on all platforms except the HPPA.
-
- --with-gnu-as -- Specify that the compiler should assume the GNU
- assembler (aka gas) is available.
-
- --with-gnu-ld -- Specify that the compiler should assume the GNU
- linker (aka gld) is available.
-
- --with-stabs -- Specify that stabs debugging information should be used
- instead of whatever format the host normally uses. Normally GCC uses the
- same debug format as the host system.
-
- --enable-multilib -- Specify that multiple target libraries
- should be built to support different target variants, calling conventions,
- etc. This is the default.
-
- --enable-threads -- Specify that the target supports threads.
- This only effects the Objective-C compiler and runtime library.
-
- --enable-threads=lib -- Specify that lib is the
- thread support library. This only effects the Objective-C compiler and
- runtime library.
-
- --with-cpu=cpu -- Specify which cpu variant the compiler should
- generate code for by default. This is currently only supported on the
- RS6000/PowerPC ports.
-
-
-Some options which only apply to building cross compilers:
-
- --with-headers=dir -- Specifies a directory which has target
- include files.
- --with-libs=dirs -- Specifies a list of directories which contain
- the target runtime libraries.
- --with-newlib -- Specifies that "newlib" is being used as the target
- C library. This causes __eprintf to be omitted from libgcc.a on the
- assumption that it will be provided by newlib.
-
-
-Note that each --enable option has a corresponding --disable option and
-that each --with option has a corresponding --without option.
-
-
-
-Last modified on December 2, 1997.
diff --git a/INSTALL/FAQ b/INSTALL/FAQ
deleted file mode 100644
index 343243ddb17..00000000000
--- a/INSTALL/FAQ
+++ /dev/null
@@ -1,322 +0,0 @@
-egcs Frequently Asked Questions
-
-
-How is egcs be different from gcc2?
-
-Six years ago, gcc version 1 had reached a point of stability. For the
-targets it could support, it worked well. It had limitations inherent in
-its design that would be difficult to resolve, so a major effort was made
-and gcc version 2 was the result. When we had gcc2 in a useful state,
-development efforts on gcc1 stopped and we all concentrated on making
-gcc2 better than gcc1 could ever be. This is the kind of step forward
-we want to make with egcs.
-
-In brief, the three biggest differences between egcs and gcc2 are
-these:
-
-
- More rexamination of basic architectual decisions of
- gcc and an interest in adding new optimizations;
-
- working with the groups who have fractured out from gcc2 (like
- the Linux folks, the Intel optimizations folks, Fortran folks)
- including more front-ends; and finally
-
- An open development model (see below) for the development process.
-
-
-These three differences will work together to result in a more
-useful compiler, a more stable compiler, a central compiler that works
-for more people, a compiler that generates better code.
-
-
-There are a lot of exciting compiler optimizations that have come
-out. We want them in gcc. There are a lot of front ends out there for
-gcc for languages like Fortran or Pascal. We want them easily
-installable by users. After six years of working on gcc2, we've come
-to see problems and limitations in the way gcc is architected; it is
-time to address these again.
-
-
-What is an open development model?
-
-With egcs, we are going to try a bazaar style[1] approach to its
-development: We're going to be making snapshots publically available
-to anyone who wants to try them; we're going to welcome anyone to join
-the development mailing list. All of the discussions on the
-development mailing list are available via the web. We're going to be
-making releases with a much higher frequency than they have been made
-in the past: We're shooting for three by the end of 1997.
-
-In addition to weekly snapshots of the egcs development sources, we
-are going to look at making the sources readable from a CVS server by
-anyone. We want to make it so external maintainers of parts of egcs
-are able to commit changes to their part of egcs directly into the
-sources without going through an intermediary.
-
-There have been many potential gcc developers who were not able to
-participate in gcc development in the past. We these people to help in
-any way they can; we ultimately want gcc to be the best compiler in the
-world.
-
-A compiler is a complicated piece of software, there will still be
-strong central maintainers who will reject patches, who will demand
-documentation of implementations, and who will keep the level of
-quality as high as it is today. Code that could use wider testing may
-be intergrated--code that is simply ill-conceived won't be.
-
-egcs is not the first piece of software to use this open development
-process; FreeBSD, the Emacs lisp repository, and Linux are a few
-examples of the bazaar style of development.
-
-With egcs, we will be adding new features and optimizations at a
-rate that has not been done since the creation of gcc2; these additions
-will inevitably have a temporarily destabilizing effect. With the help
-of developers working together with this bazaar style development, the
-resulting stability and quality levels will be better than we've had
-before.
-
-cathedral-vs-bazaar[1]
- We've been discussing different development models a lot over the
- past few months. The paper which started all of this introduced two
- terms: A cathedral development model versus a bazaar
- development model. The paper is written by Eric S. Raymond, it is
- called `` http://locke.ccil.org/~esr/writings/cathedral.html" The
- Cathedral and the Bazaar''. The paper is a useful starting point
- for discussions.
-
-
-
-bits/libc-lock.h: No such file or directory
-egcs includes a tightly integrated libio and libstdc++ implementation which
-can cause problems on hosts which have libio integrated into their C library
-(most notably Linux).
-
-We believe that we've solved the major technical problems for the most
-common versions of libc found on Linux systems. However, some versions
-of Linux use pre-release versions of glibc2, which egcs has trouble detecting
-and correctly handling.
-
-If you're using one of these pre-release versions of glibc2, you may get
-a message "bits/libc-lock.h: No such file or directory" when building egcs.
-Unfortunately, to fix this problem you will need to update your C library to
-glibc2.0.5c.
-
-Late breaking news: we may have at least a partial solution for these
-problems. So this FAQ entry may no longer be needed.
-
-
-`_IO_stdfile_0_lock' was not declared in this scope
-If you get this error, it means either egcs incorrectly guessed what version
-of libc is installed on your linux system, or you incorrectly specified a
-version of glibc when configuring egcs.
-
-If you did not provide a target name when configuring egcs, then you've
-found a bug which needs to be reported. If you did provide a target name at
-configure time, then you should reconfigure without specifying a target name.
-
-
-Problems building the Fortran compiler
-The Fortran front end can not be built with most vendor compilers; it must
-be built with gcc. As a result, you may get an error if you do not follow
-the install instructions carefully.
-
-In particular, instead of using "make" to build egcs, you should use
-"make bootstrap" if you are building a native compiler or "make cross"
-if you are building a cross compiler.
-
-It has also been reported that the Fortran compiler can not be built
-on Red Hat 4.X linux for the Alpha. Fixing this may require upgrading
-binutils or to Red Hat 5.0; we'll provide more information as it becomes
-available.
-
-
-Problems building on MIPS platforms
-egcs requires the use of GAS on all versions of Irix, except Irix 6 due
-to limitations in older Irix assemblers.
-
- Either of these messages indicates that you are using the MIPS assembler
-when instead you should be using GAS.
-
- as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
- .4byte $LECIE1-$LSCIE1
- as0: Error: ./libgcc2.c, line 1:malformed statement
-
-
-
- as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression
- .word $LECIE1-$LSCIE1
-
-
- For Irix 6, you should use the native assembler as GAS is not supported
-on Irix 6.
-
-
-Problems with exception handling on x86 platforms
-If you are using the GNU assembler (aka gas) on an x86 platform and
-exception handling is not working correctly, then odds are you're using a
-buggy assembler.
-
-We recommend binutils-2.8.0.1.15 or newer.
-"ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz binutils-2.8.0.1.15 source
-ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz binutils-2.8.0.1.15 x86 binary for libc5
-ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz binutils-2.8.0.1.15 x86 binary for glibc2
-Or, you can try a
-ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz binutils snapshot; however, be aware that the binutils snapshot is untested
-and may not work (or even build). Use it at your own risk.
-
-
-Bootstrap comparison failures on HPs
-If you bootstrap the compiler on hpux10 using the HP assembler instead of
-gas, every file will fail the comparison test.
-
-The HP asembler inserts timestamps into object files it creates, causing
-every file to be different. The location of the timestamp varies for each
-object file, so there's no real way to work around this mis-feature.
-
-Odds are your compiler is fine, but there's no way to be certain.
-
-If you use GAS on HPs, then you will not run into this problem because
-GAS never inserts timestamps into object files. For this and various other
-reasons we highly recommend using GAS on HPs.
-
-
-Bootstrap loops rebuilding cc1 over and over
-When building egcs, the build process loops rebuilding cc1 over and
-over again. This happens on mips-sgi-irix5.2, and possibly other platforms.
-
-This is probably a bug somewhere in the egcs Makefile. Until we find and
-fix this bug we recommend you use GNU make instead of vendor supplied make
-programs.
-
-
-Dynamic linker is unable to find GCC libraries
-This problem manifests itself by programs not finding shared libraries
-they depend on when the programs are started. Note this problem often manifests
-itself with failures in the libio/libstdc++ tests after configuring with
---enable-shared and building egcs.
-
-GCC does not specify a runpath so that the dynamic linker can find dynamic
-libraries at runtime.
-
-The short explaination is that if you always pass a -R option to the
-linker, then your programs become dependent on directories which
-may be NFS mounted, and programs may hang unnecessarily when an
-NFS server goes down.
-
-The problem is not programs that do require the directories; those
-programs are going to hang no matter what you do. The problem is
-programs that do not require the directories.
-
-SunOS effectively always passed a -R option for every -L option;
-this was a bad idea, and so it was removed for Solaris. We should
-not recreate it.
-
-
-Unable to run the testsuite
-If you get a message about unable to find "standard.exp" when trying to
-run the egcs testsuites, then your dejagnu is too old to run the egcs tests.
-You will need to get a newer version of dejagnu; we've made a
-
-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
-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 <file>.new to be changed to <file>-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
-mailing lists on the main egcs page for instructions on how to subscribe.
-
-When using the diff files to update from older snapshots to newer snapshots,
-make sure to use "-E" and "-p" arguments to patch so that empty files are
-deleted and full pathnames are provided to patch. If your version of
-patch does not support "-E", you'll need to get a newer version. Also note
-that you may need autoconf, autoheader and various other programs if you use
-diff files to update from one snapshot to the next.
-
-
-How to install both egcs and gcc2
-It may be desirable to install both egcs and gcc2 on the same system. This
-can be done by using different prefix paths at configure time and a few
-symlinks.
-
-Basically, configure the two compilers with different --prefix options,
-then build and install each compiler. Assume you want "gcc" to be the egcs
-compiler and available in /usr/local/bin; also assume that you want "gcc2"
-to be the gcc2 compiler and also available in /usr/local/bin.
-
-The easiest way to do this is to configure egcs with --prefix=/usr/local/egcs
-and gcc2 with --prefix=/usr/local/gcc2. Build and install both compilers.
-Then make a symlink from /usr/local/bin/gcc to /usr/local/egcs/bin/gcc and
-from /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links
-for the "g++", "c++" and "g77" compiler drivers.
-
-
-Problems building Linux kernels
-If you installed a recent binutils/gas snapshot on your Linux system,
-you may not be able to build the kernel because objdump does not understand
-the "-k" switch. The solution for this problem is to remove /usr/bin/encaps.
-
-You may get an internal compiler error compiling process.c in newer
-versions of the Linux kernel on x86 machines. This is a bug in an asm
-statement in process.c, not a bug in egcs. XXX How to fix?!?
-
-You may get errors with the X driver of the form
-_X11TransSocketUNIXConnect: Can't connect: errno = 111
-
-It's a kernel bug. The function sys_iopl in arch/i386/kernel/process.c
-does an illegal hack which used to work but is now broken since GCC optimizes
-more aggressively . The newer 2.1.x kernels already have a fix which should
-also work in 2.0.32.
-
-
-Virtual memory exhausted error
- This error means your system ran out of memory; this can happen for large
-files, particularly when optimizing. If you're getting this error you should
-consider trying to simplify your files or reducing the optimization level.
-
-Note that using -pedantic or -Wreturn-type can cause an explosion in the
-amount of memory needed for template-heavy C++ code, such as code that uses
-STL. Also note that -Wall includes -Wreturn-type, so if you use -Wall you
-will need to specify -Wno-return-type to turn it off.
-
-
-GCC can not find GAS
-Some configurations like irix4, irix5, hpux* require the use of the GNU
-assembler intead of the system assembler. To ensure that egcs finds the GNU
-assembler, you should configure the GNU assembler with the same --prefix
-option as you used for egcs. Then build & install the GNU assembler.
-
-
-egcs does not work on Red Hat 5.0
- egcs does not currently work with Red Hat 5.0; we'll update this
-entry with more information as it becomes available.
-
-
-Last modified: December 2, 1997
diff --git a/INSTALL/FINALINSTALL b/INSTALL/FINALINSTALL
deleted file mode 100644
index 5d893c563e0..00000000000
--- a/INSTALL/FINALINSTALL
+++ /dev/null
@@ -1,19 +0,0 @@
-Final install egcs-1.0
-
-Now that egcs has been built and tested, you can install it with
-`cd objdir; make install' for a native compiler or
-`cd objdir; make install LANGUAGES="c c++"' for a cross compiler
-(note installing cross compilers will be easier in the next release!).
-
-
-That step completes the installation of egcs; user level binaries can
-be found in prefix/bin where prefix is the value you specified
-with the --prefix to configure (or /usr/local by default).
-
-If you don't mind, please send egcs@cygnus.com a short mail message
-indicating that you successfully built and installed egcs. Include
-the output from running srcdir/config.guess.
-
-If you find a bug in egcs, please report it to egcs-bugs@cygnus.com
-
-Last modified on December 2, 1997.
diff --git a/INSTALL/INDEX b/INSTALL/INDEX
deleted file mode 100644
index c651389f3f1..00000000000
--- a/INSTALL/INDEX
+++ /dev/null
@@ -1,34 +0,0 @@
-Installing egcs-1.0
-
-This document describes the generic installation procedure for egcs as
-well as detailing some target specific installation instructions for egcs.
-
-egcs includes several components that previously were separate distributions
-with their own installation instructions. This document supercedes all
-package specific installation instructions. We provide the component specific
-installation information in the source distribution for historical reference
-purposes only.
-
-We recommend you read the entire generic installation instructions as
-well as any target specific installation instructions before you proceed
-to configure, build, test and install egcs.
-
-If something goes wrong in the configure, build, test or install
-procedures, first double check that you followed the generic and target
-specific installation instructions carefully. Then check the EGCS FAQ
-(FAQ) to see if your problem is covered before you file a bug report.
-
-The installation procedure is broken into four steps.
-
-
- Configure see CONFIGURE
- Build see BUILD
- Test see TEST
- Final Install see FINALINSTALL
-
-
-Before starting the build/install procedure please browse the
-host/target specific installation notes (SPECIFIC).
-
-Last modified on December 2, 1997.
-
diff --git a/INSTALL/README b/INSTALL/README
index 786ca89ece4..67db7da23c4 100644
--- a/INSTALL/README
+++ b/INSTALL/README
@@ -1,14 +1,9 @@
-This directory contains installation instrutions for egcs-1.00.
+This directory has been obsoleted for egcs snapshots and CVS access.
-We're providing installation instructions in two forms, html and
-plaintext.
+Instead check out the toplevel "wwwdocs" as a sibling of your egcs
+tree or read these files via the egcs web site
+http://egcs.cygnus.com
-index.html is the toplevel install file for html browsers.
-
-INDEX is the toplevel install file in plaintext form.
-
-The most recent HTML installation instructions for egcs can be obtained from
-the egcs web site:
-
-http://www.cygnus.com/egcs/install
+Copies of the relavent files will be copied into this directory for
+releases.
diff --git a/INSTALL/SPECIFIC b/INSTALL/SPECIFIC
deleted file mode 100644
index 386836b83d9..00000000000
--- a/INSTALL/SPECIFIC
+++ /dev/null
@@ -1,106 +0,0 @@
-Host/Target specific installation notes for egcs-1.0
-
-alpha*-*-*
-No specific installation needs/instructions.
-
-
-i?86-*-linux*
-You will need binutils-2.8.1.0.15 or newer for exception handling to work.
-
-i?86-*-sco3.2v5*
-The SCO assembler is currently required. The GNU assembler is not up
-to the task of switching between ELF and COFF at runtime.
-
-Unlike various prereleases of GCC, that used '-belf' and defaulted to
-COFF, you must now use the '-melf' and '-mcoff' flags to toggle between
-the two object file formats. ELF is now the default.
-
-Look in gcc/config/i386/sco5.h (search for "messy") for additional
-OpenServer-specific flags.
-
-
-
-hppa*-hp-hpux*
-We highly recommend using gas/binutils-2.8 on all hppa platforms; you
-may encounter a variety of problems when using the HP assembler.
-
-hppa*-hp-hpux9
-The HP assembler has major problems on this platform. We've tried to work
-around the worst of the problems. However, those workarounds may be causing
-linker crashes in some circumstances; the workarounds also probably prevent
-shared libraries from working. Use the GNU assembler to avoid these problems.
-
-The configuration scripts for egcs will also trigger a bug in the hpux9
-shell. To avoid this problem set CONFIG_SHELL to /bin/ksh and SHELL to
-/bin/ksh in your environment.
-
-hppa*-hp-hpux10
-For hpux10.20, we highly recommend you pick up the latest sed
-patch from HP. HP has two sites which provide patches free of charge.
-
-http://us-support.external.hp.com for US, Canada, Asia-Pacific, and
-Latin-America
-http://europe-support.external.hp.com for Europe
-
-Retrieve patch PHCO_12862.
-
-The HP assembler on these systems is much better than the hpux9 assembler,
-but still has some problems. Most notably the assembler inserts timestamps
-into each object file it creates, causing the 3-stage comparison test to fail
-during a "make bootstrap". You should be able to continue by saying "make all"
-after getting the failure from "make bootstrap".
-
-m68k-*-nextstep*
-You absolutely must use GNU sed and GNU make on this platform.
-
-If you try to build the integrated C++ & C++ runtime libraries on this system
-you will run into trouble with include files. The way to get around this is
-to use the following sequence. Note you must have write permission to
-prefix for this sequence to work.
-
-cd objdir
-make all-texinfo all-bison all-byacc all-binutils all-gas all-ld
-cd gcc
-make bootstrap
-make install-headers-tar
-cd ..
-make bootstrap3
-
-m68k-sun-sunos4.1.1
-It is reported that you may need the GNU assembler on this platform.
-
-mips*-sgi-irix4
-mips*-sgi-irix5
-You must use GAS on these platforms, the native assembler can not handle the
-code for exception handling support on this platform.
-
-These systems don't have ranlib, which various components in egcs need; you
-should be able to avoid this problem by installing GNU binutils, which includes
-a functional ranlib for this system.
-
-You may get the following warning on irix4 platforms, it can be safely
-ignored.
-
- warning: foo.o does not have gp tables for all its sections.
-
-mips*-sgi-irix6
-You must not use GAS on irix6 platforms; doing so will only cause problems.
-
-These systems don't have ranlib, which various components in egcs need; you
-should be able to avoid this problem by making a dummy script called ranlib
-which just exits with zero status and placing it in your path.
-
-rs6000-ibm-aix*
-powerpc-ibm-aix*
-At least one person as reported problems with older versions of gnu-make on
-this platform. make-3.76 is reported to work correctly.
-
-powerpc-*-linux-gnu*
-You will need binutils-2.8.1.0.17 from ftp://ftp.yggdrasil.com/private/hjl for
-a working egcs. It is strongly recommended to recompile binutils with egcs
-if you initially built it with gcc-2.7.2.*.
-
-
-exception handling
-XXX Linux stuff
-Last modified on December 2, 1997.
diff --git a/INSTALL/TEST b/INSTALL/TEST
deleted file mode 100644
index 749204571ca..00000000000
--- a/INSTALL/TEST
+++ /dev/null
@@ -1,28 +0,0 @@
-Testing egcs-1.0
-
-Before you install egcs, you might wish to run the egcs testsuite; this
-step is optional and may require you to download additional software.
-
-First, you must have downloaded the egcs testsuites; the full distribution
-contains testsuites. If you downloaded the "core" compiler plus any front
-ends, then you do not have the testsuites. You can download the testsuites
-from the same site where you downloaded the core distribution and language
-front ends.
-
-Second, you must have a new version of dejagnu on your system; dejagnu-1.3
-will not work. We have made a dejagnu snapshot
-ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz
-dejagnu snapshot available in ftp.cygnus.com:/pub/egcs/infrastructure until
-a new version of dejagnu can be released.
-
-Assuming you've got the testsuites unpacked and have installed an appropriate
-dejagnu, you can run the testsuite with "cd objdir; make -k check".
-This may take a long time. Go get some lunch.
-
-The testing process will try to test as many components in the egcs
-distrubution as possible, including the C, C++ and Fortran compiler as
-well as the C++ runtime libraries.
-
- How to interpret test results XXX.
-
-Last modified on December 2, 1997.
diff --git a/INSTALL/build.html b/INSTALL/build.html
deleted file mode 100644
index 750b2c4a5f2..00000000000
--- a/INSTALL/build.html
+++ /dev/null
@@ -1,66 +0,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:
-
-
-
-
-
-
-
-
-
-
- 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.
-
- For a cross build, issue the command "make cross", which performs the
-following steps:
-
-
-
-
-
-
-
- Note that if an error occurs in any step the make process will exit.
-
-
- 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:
-
- target specification
- options specification
-
- Use options to override several configure time options for
-egcs. A partial list of supported options:
-
- Some options which only apply to building cross compilers:
- Note that each --enable option has a corresponding --disable option and
-that each --with option has a corresponding --without option.
-
-
-
- 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:
-
- 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.
-
- 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.
-
- 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.
-
- 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.
-
- 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.
-
- 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.
-
- For Irix 6, you should use the native assembler as GAS is not supported
-on Irix 6.
-
- 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.
- 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.
-
- 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.
-
- 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.
-
- 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
-
-dejagnu snapshot available until a new version of dejagnu can be released.
-
- 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
-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 <file>.new to be changed to <file>-new.
-
- 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
-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.
-
- 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.
-
- If you installed a recent binutils/gas snapshot on your Linux system,
-you may not be able to build the kernel because objdump does not understand
-the "-k" switch. The solution for this problem is to remove /usr/bin/encaps.
-
- You may get an internal compiler error compiling process.c in newer
-versions of the Linux kernel on x86 machines. This is a bug in an asm
-statement in process.c, not a bug in egcs. XXX How to fix?!?
-
- You may get errors with the X driver of the form
- 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.
-
- 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.
-
- Some configurations like irix4, irix5, hpux* require the use of the GNU
-assembler intead of the system assembler. To ensure that egcs finds the GNU
-assembler, you should configure the GNU assembler with the same --prefix
-option as you used for egcs. Then build & install the GNU assembler.
-
- egcs does not currently work with Red Hat 5.0; we'll update this
-entry with more information as it becomes available.
-
- Return to the egcs home page
- Last modified: December 2, 1997
-
-
-
diff --git a/INSTALL/finalinstall.html b/INSTALL/finalinstall.html
deleted file mode 100644
index c7984f106a7..00000000000
--- a/INSTALL/finalinstall.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
- Now that egcs has been built and tested, you can install it with
-`cd objdir; make install' for a native compiler or
-`cd objdir; make install LANGUAGES="c c++"' for a cross compiler
-(note installing cross compilers will be easier in the next release!).
-
-
- That step completes the installation of egcs; user level binaries can
-be found in prefix/bin where prefix is the value you specified
-with the --prefix to configure (or /usr/local by default).
-
- If you don't mind, please send egcs@cygnus.com a short mail message
-indicating that you successfully built and installed egcs. Include
-the output from running srcdir/config.guess.
-
- If you find a bug in egcs, please report it to
-egcs-bugs@cygnus.com.
-
-
- 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
-FAQ to see if your problem is covered before you file
-a bug report.
-
- The installation procedure is broken into four steps.
-
- Before starting the build/install procedure please browse the
-host/target specific installation notes.
-
-Building egcs-1.0
-
-
-
-
-
-
-
-
-Last modified on December 2, 1997.
-
-
-
diff --git a/INSTALL/configure.html b/INSTALL/configure.html
deleted file mode 100644
index ff26b384b9c..00000000000
--- a/INSTALL/configure.html
+++ /dev/null
@@ -1,122 +0,0 @@
-
-
-Configuring egcs-1.0
-
-
-
-
-
-
-
% mkdir objdir
-
% cd objdir
-
% srcdir/configure [target] [options]
-
-
-
-
-
-
-
-
-
These additional options control where certain parts of the distribution
- are installed. Normally you should not need to use these options.
-
-
-
-
-
-
-
-Last modified on December 2, 1997.
-
-
-
diff --git a/INSTALL/faq.html b/INSTALL/faq.html
deleted file mode 100644
index cbc82dafe12..00000000000
--- a/INSTALL/faq.html
+++ /dev/null
@@ -1,365 +0,0 @@
-
-
-egcs Frequently Asked Questions
-
-
-
-
-
-How is egcs be different from gcc2?
-
-
-
-
-
-What is an open development model?
-
-
-[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 ``The
- Cathedral and the Bazaar''. The paper is a useful starting point
- for discussions.
-
-
-
-
-bits/libc-lock.h: No such file or directory
-
-`_IO_stdfile_0_lock' was not declared in this scope
-
-Problems building the Fortran compiler
-
-Problems building on MIPS platforms
-
- as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
- .4byte $LECIE1-$LSCIE1
- as0: Error: ./libgcc2.c, line 1:malformed statement
-
-
-
-
- as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression
- .word $LECIE1-$LSCIE1
-
-
-
-
-
- Problems with exception handling on x86 platforms
-
binutils-2.8.0.1.15 source
-
binutils-2.8.0.1.15 x86 binary for libc5
-
binutils-2.8.0.1.15 x86 binary for glibc2
-Or, you can try a
- 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
-
- Bootstrap loops rebuilding cc1 over and over
-
- Dynamic linker is unable to find GCC libraries
-
- Unable to run the testsuite
-
- How to build a cross compiler
-
- Snapshots, how, when, why
-
- How to install both egcs and gcc2
-
- Problems building Linux kernels
-
-_X11TransSocketUNIXConnect: Can't connect: errno = 111
-
-
-
- Virtual memory exhausted error
-
- GCC can not find GAS
-
- egcs does not work on Red Hat 5.0
-
-Final install egcs-1.0
-
-
-Last modified on December 2, 1997.
-
-
-
diff --git a/INSTALL/index.html b/INSTALL/index.html
deleted file mode 100644
index 5c556ec7615..00000000000
--- a/INSTALL/index.html
+++ /dev/null
@@ -1,47 +0,0 @@
-
-
-Installing egcs-1.0
-
-
-Return to the egcs home page
-
-
-
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.
-
-
Systems based on OpenServer before 5.0.4 (uname -X
will
-tell you what you're running) require TLS597 from ftp.sco.com/TLS for
-C++ constructors and destructors to work right.
-
-
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.
-
-XXX How to make sure gcc finds/uses gas.
-
-
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.
-
-
US, Canada, Asia-Pacific, and
-Latin-America
-
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 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 -
Before you install egcs, you might wish to run the egcs testsuite; this -step is optional and may require you to download additional software. - -
First, you must have downloaded the egcs testsuites; the full distribution -contains testsuites. If you downloaded the "core" compiler plus any front -ends, then you do not have the testsuites. You can download the testsuites -from the same site where you downloaded the core distribution and language -front ends. - -
Second, you must have a new version of dejagnu on your system; dejagnu-1.3 -will not work. We have made a - -dejagnu snapshot 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. - -