+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.
-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
-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.
-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 <file>.new to be changed to <file>-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 <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 <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
-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
-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
-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
-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
<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.
<p>
<hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
</body>
</html>
<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
<p>
<hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
</body>
</html>
<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>
<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>
<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
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).
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
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.
<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>
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?!?
_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.
<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>
<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
<p>
<hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
</body>
</html>
<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.
<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.
</body>
</html>
<hr>
-<i>Last modified on December 2, 1997.</i>
+<i>Last modified on Jan 2, 1998.</i>
<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.
<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
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>
<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.
<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.
<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>
+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
/* 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.
%{!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}"
/* 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.
__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) */
/* 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) ();
.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 " ].\|.\|."
@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.
-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)";
projects / thirdparty / gcc.git / commitdiff
