diff options
author | law <law@138bc75d-0d04-0410-961f-82ee72b054a4> | 1998-01-02 23:38:15 +0000 |
---|---|---|
committer | law <law@138bc75d-0d04-0410-961f-82ee72b054a4> | 1998-01-02 23:38:15 +0000 |
commit | ded0ac3ebfeae1095b817b96187879d1aafccd76 (patch) | |
tree | 0295671a2946cc0123e5fbb4763e73f69741633e | |
parent | 944c35c34aca7cb7c415932e7f249447055a1abd (diff) |
Various egcs-1.0.1 related changes.egcs_1_0_1_release
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/egcs_1_00_branch@17282 138bc75d-0d04-0410-961f-82ee72b054a4
-rw-r--r-- | ChangeLog | 4 | ||||
-rw-r--r-- | INSTALL/BUILD | 102 | ||||
-rw-r--r-- | INSTALL/CONFIGURE | 196 | ||||
-rw-r--r-- | INSTALL/FAQ | 738 | ||||
-rw-r--r-- | INSTALL/FINALINSTALL | 39 | ||||
-rw-r--r-- | INSTALL/INDEX | 78 | ||||
-rw-r--r-- | INSTALL/SPECIFIC | 220 | ||||
-rw-r--r-- | INSTALL/TEST | 56 | ||||
-rw-r--r-- | INSTALL/build.html | 6 | ||||
-rw-r--r-- | INSTALL/configure.html | 6 | ||||
-rw-r--r-- | INSTALL/faq.html | 169 | ||||
-rw-r--r-- | INSTALL/finalinstall.html | 6 | ||||
-rw-r--r-- | INSTALL/index.html | 8 | ||||
-rw-r--r-- | INSTALL/specific.html | 18 | ||||
-rw-r--r-- | INSTALL/test.html | 8 | ||||
-rw-r--r-- | gcc/ChangeLog | 7 | ||||
-rw-r--r-- | gcc/config/mips/iris6.h | 4 | ||||
-rw-r--r-- | gcc/crtstuff.c | 18 | ||||
-rw-r--r-- | gcc/gcc.1 | 4 | ||||
-rw-r--r-- | gcc/gcc.texi | 2 | ||||
-rw-r--r-- | gcc/version.c | 2 |
21 files changed, 1032 insertions, 659 deletions
diff --git a/ChangeLog b/ChangeLog index c1e01ea8e2f..415842c98b4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +Fri Jan 2 11:34:38 1998 Jeffrey A Law (law@cygnus.com) + + * egcs-1.0.1 release. + Wed Dec 3 07:55:59 1997 Jeffrey A Law (law@cygnus.com) * egcs-1.0 release. diff --git a/INSTALL/BUILD b/INSTALL/BUILD index 03779e80830..05e0902052e 100644 --- a/INSTALL/BUILD +++ b/INSTALL/BUILD @@ -1,54 +1,50 @@ -Building egcs-1.0 - -Now that egcs is configured, you are ready to build the compiler and -runtime libraries. - -We highly recommend that egcs be built using gnu-make; other -versions make work, then again they might not. To be safe build with gnu-make. - -Building a native compiler -For a native build issue the command "make bootstrap". This will build -the entire egcs compiler system, which includes the following steps: - - - Build host tools necessary to build the compiler such as texinfo, bison, - gperf. - - Build target tools for use by the compiler such as gas, gld, and binutils. - - Perform a 3-stage bootstrap of the compiler. - - Perform a comparison test of the stage2 and stage3 compilers. - - Build runtime libraries using the stage3 compiler from the previous step. - - -If you are short on disk space you might consider "make bootstrap-lean" -instead. This is identical to "make bootstrap" except that object files -from the stage1 and stage2 of the 3-stage bootstrap of the compiler are -deleted as soon as they are no longer needed. - -Building a cross compiler - -We recommend reading the crossgcc FAQ for information about building -cross compilers. -"ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1" - -For a cross build, issue the command "make cross", which performs the -following steps: - - Build host tools necessary to build the compiler such as texinfo, bison, - gperf. - - Build target tools for use by the compiler such as gas, gld, and binutils. - - Build the compiler (single stage only). - - Build runtime libraries using the compiler from the previous step. - - -Note that if an error occurs in any step the make process will exit. - - -Last modified on December 2, 1997. + Building egcs-1.0.1 + + Now that egcs is configured, you are ready to build the compiler and + runtime libraries. + + We highly recommend that egcs be built using gnu-make; other versions + make work, then again they might not. To be safe build with gnu-make. + + Building a native compiler + + For a native build issue the command "make bootstrap". This will build + the entire egcs compiler system, which includes the following steps: + * Build host tools necessary to build the compiler such as texinfo, + bison, gperf. + * Build target tools for use by the compiler such as gas, gld, and + binutils. + * Perform a 3-stage bootstrap of the compiler. + * Perform a comparison test of the stage2 and stage3 compilers. + * Build runtime libraries using the stage3 compiler from the + previous step. + + If you are short on disk space you might consider "make + bootstrap-lean" instead. This is identical to "make bootstrap" except + that object files from the stage1 and stage2 of the 3-stage bootstrap + of the compiler are deleted as soon as they are no longer needed. + + Building a cross compiler + + We recommend reading the [1]crossgcc FAQ for information about + building cross compilers. + + For a cross build, issue the command "make cross", which performs the + following steps: + * Build host tools necessary to build the compiler such as texinfo, + bison, gperf. + * Build target tools for use by the compiler such as gas, gld, and + binutils. + * Build the compiler (single stage only). + * Build runtime libraries using the compiler from the previous step. + + Note that if an error occurs in any step the make process will exit. + + _________________________________________________________________ + + Last modified on Jan 2, 1998. + +References + + 1. ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1 diff --git a/INSTALL/CONFIGURE b/INSTALL/CONFIGURE index 403657fab0c..8bca3494a1e 100644 --- a/INSTALL/CONFIGURE +++ b/INSTALL/CONFIGURE @@ -1,108 +1,90 @@ -Configuring egcs-1.0 -Like most GNU software, egcs must be configured before it can be built. -This document attempts to describe the recommended configuration procedure -for both native and cross targets. - -We use srcdir to refer to the toplevel source directory for -egcs; we use objdir to refer to the toplevel build/object -directory for egcs. - -First, we highly recommend that egcs be built into a separate -directory than the sources. This is how we generally build egcs; building -where srcdir == objdir should still work, but doesn't get -extensive testing. - -Second, when configuring a native system, either "cc" must be in your -path or you must set CC in your environment before running configure. -Otherwise the configuration scripts may fail. - -To configure egcs: - - % mkdir objdir - % cd objdir - % srcdir/configure [target] [options] - - -target specification - - egcs has code to correctly determine the correct value for - target for nearly all native systems. Therefore, we highly - recommend you not provide a configure target when configuring a - native compiler. - - target must be specified when configuring a cross compiler; - examples of valid targets would be i960-rtems, m68k-coff, sh-elf, etc. - - -options specification - -Use options to override several configure time options for -egcs. A partial list of supported options: - - - --prefix=dirname -- Specify the toplevel installation - directory. This is the recommended way to install the tools into a directory - other than the default. The toplevel installation directory defaults to - /usr/local. - - These additional options control where certain parts of the distribution - are installed. Normally you should not need to use these options. - - --with-local-prefix=dirname -- Specify the installation - directory for local include files. The default is /usr/local. - - --with-gxx-include-dir=dirname -- Specify the installation - directory for g++ header files. The default is /usr/local/include/g++. - - - --enable-shared -- Build shared versions of the C++ runtime - libraries if supported --disable-shared is the default. - - --enable-haifa -- Enable the new Haifa instruction scheduler in the - compiler; the new scheduler can significantly improve code on some targets. - --disable-haifa is currently the default on all platforms except the HPPA. - - --with-gnu-as -- Specify that the compiler should assume the GNU - assembler (aka gas) is available. - - --with-gnu-ld -- Specify that the compiler should assume the GNU - linker (aka gld) is available. - - --with-stabs -- Specify that stabs debugging information should be used - instead of whatever format the host normally uses. Normally GCC uses the - same debug format as the host system. - - --enable-multilib -- Specify that multiple target libraries - should be built to support different target variants, calling conventions, - etc. This is the default. - - --enable-threads -- Specify that the target supports threads. - This only effects the Objective-C compiler and runtime library. - - --enable-threads=lib -- Specify that lib is the - thread support library. This only effects the Objective-C compiler and - runtime library. - - --with-cpu=cpu -- Specify which cpu variant the compiler should - generate code for by default. This is currently only supported on the - RS6000/PowerPC ports. - - -Some options which only apply to building cross compilers: - - --with-headers=dir -- Specifies a directory which has target - include files. - --with-libs=dirs -- Specifies a list of directories which contain - the target runtime libraries. - --with-newlib -- Specifies that "newlib" is being used as the target - C library. This causes __eprintf to be omitted from libgcc.a on the - assumption that it will be provided by newlib. - - -Note that each --enable option has a corresponding --disable option and -that each --with option has a corresponding --without option. - - - -Last modified on December 2, 1997. + Configuring egcs-1.0.1 + + Like most GNU software, egcs must be configured before it can be + built. This document attempts to describe the recommended + configuration procedure for both native and cross targets. + + We use srcdir to refer to the toplevel source directory for egcs; we + use objdir to refer to the toplevel build/object directory for egcs. + + First, we highly recommend that egcs be built into a separate + directory than the sources. This is how we generally build egcs; + building where srcdir == objdir should still work, but doesn't get + extensive testing. + + Second, when configuring a native system, either "cc" must be in your + path or you must set CC in your environment before running configure. + Otherwise the configuration scripts may fail. + + To configure egcs: + + + % mkdir objdir + % cd objdir + % srcdir/configure [target] [options] + + target specification + * egcs has code to correctly determine the correct value for target + for nearly all native systems. Therefore, we highly recommend you + not provide a configure target when configuring a native compiler. + * target must be specified when configuring a cross compiler; + examples of valid targets would be i960-rtems, m68k-coff, sh-elf, + etc. + + options specification + + Use options to override several configure time options for egcs. A + partial list of supported options: + * --prefix=dirname -- Specify the toplevel installation directory. + This is the recommended way to install the tools into a directory + other than the default. The toplevel installation directory + defaults to /usr/local. + These additional options control where certain parts of the + distribution are installed. Normally you should not need to use + these options. + + --with-local-prefix=dirname -- Specify the installation + directory for local include files. The default is /usr/local. + + --with-gxx-include-dir=dirname -- Specify the installation + directory for g++ header files. The default is + /usr/local/include/g++. + * --enable-shared -- Build shared versions of the C++ runtime + libraries if supported --disable-shared is the default. + * --enable-haifa -- Enable the new Haifa instruction scheduler in + the compiler; the new scheduler can significantly improve code on + some targets. --disable-haifa is currently the default on all + platforms except the HPPA. + * --with-gnu-as -- Specify that the compiler should assume the GNU + assembler (aka gas) is available. + * --with-gnu-ld -- Specify that the compiler should assume the GNU + linker (aka gld) is available. + * --with-stabs -- Specify that stabs debugging information should be + used instead of whatever format the host normally uses. Normally + GCC uses the same debug format as the host system. + * --enable-multilib -- Specify that multiple target libraries should + be built to support different target variants, calling + conventions, etc. This is the default. + * --enable-threads -- Specify that the target supports threads. This + only effects the Objective-C compiler and runtime library. + * --enable-threads=lib -- Specify that lib is the thread support + library. This only effects the Objective-C compiler and runtime + library. + * --with-cpu=cpu -- Specify which cpu variant the compiler should + generate code for by default. This is currently only supported on + the RS6000/PowerPC ports. + + Some options which only apply to building cross compilers: + * --with-headers=dir -- Specifies a directory which has target + include files. + * --with-libs=dirs -- Specifies a list of directories which contain + the target runtime libraries. + * --with-newlib -- Specifies that "newlib" is being used as the + target C library. This causes __eprintf to be omitted from + libgcc.a on the assumption that it will be provided by newlib. + + Note that each --enable option has a corresponding --disable option + and that each --with option has a corresponding --without option. + + _________________________________________________________________ + + Last modified on Jan 2, 1998. diff --git a/INSTALL/FAQ b/INSTALL/FAQ index 343243ddb17..17ebaa19b0f 100644 --- a/INSTALL/FAQ +++ b/INSTALL/FAQ @@ -1,322 +1,506 @@ -egcs Frequently Asked Questions - + egcs Frequently Asked Questions + + 1. [1]How is egcs be different from gcc2? + 2. [2]What is an open development model? + 3. [3]Releases and Forking + 4. [4]bits/libc-lock.h: No such file or directory + 5. [5]`_IO_stdfile_0_lock' was not declared in this scope + 6. [6]Problems building the Fortran compiler + 7. [7]Problems building on MIPS platforms + 8. [8]Problems with exception handling on x86 platforms + 9. [9]Bootstrap comparison failures on HPs + 10. [10]Bootstrap loops rebuilding cc1 over and over + 11. [11]Dynamic linker is unable to find GCC libraries + 12. [12]libstdc++/libio tests fail badly with --enable-shared + 13. [13]Unable to run the testsuite + 14. [14]How to build a cross compiler + 15. [15]How to install both gcc2 and egcs + 16. [16]Snapshots, how, when, why + 17. [17]Problems building Linux kernels + 18. [18]Virtual memory exhausted + 19. [19]GCC can not find GAS + 20. [20]egcs does not work on Red Hat 5.0 + 21. [21]Unable to bootstrap on x86 Solaris2.{5,6} + 22. [22]EGCS with Windows + 23. [23]cpp: Usage:... Error + [24]EGCS will not build KDE + _____________________________________________________________ + How is egcs be different from gcc2? -Six years ago, gcc version 1 had reached a point of stability. For the -targets it could support, it worked well. It had limitations inherent in -its design that would be difficult to resolve, so a major effort was made -and gcc version 2 was the result. When we had gcc2 in a useful state, -development efforts on gcc1 stopped and we all concentrated on making -gcc2 better than gcc1 could ever be. This is the kind of step forward -we want to make with egcs. - -In brief, the three biggest differences between egcs and gcc2 are -these: - - - More rexamination of basic architectual decisions of - gcc and an interest in adding new optimizations; - - working with the groups who have fractured out from gcc2 (like - the Linux folks, the Intel optimizations folks, Fortran folks) - including more front-ends; and finally - - An open development model (see below) for the development process. - - -These three differences will work together to result in a more -useful compiler, a more stable compiler, a central compiler that works -for more people, a compiler that generates better code. - - -There are a lot of exciting compiler optimizations that have come -out. We want them in gcc. There are a lot of front ends out there for -gcc for languages like Fortran or Pascal. We want them easily -installable by users. After six years of working on gcc2, we've come -to see problems and limitations in the way gcc is architected; it is -time to address these again. - - + Six years ago, gcc version 1 had reached a point of stability. For + the targets it could support, it worked well. It had limitations + inherent in its design that would be difficult to resolve, so a + major effort was made and gcc version 2 was the result. When we + had gcc2 in a useful state, development efforts on gcc1 stopped + and we all concentrated on making gcc2 better than gcc1 could ever + be. This is the kind of step forward we want to make with egcs. + In brief, the three biggest differences between egcs and gcc2 are + these: + + More rexamination of basic architectual decisions of gcc and + an interest in adding new optimizations; + + working with the groups who have fractured out from gcc2 + (like the Linux folks, the Intel optimizations folks, Fortran + folks) including more front-ends; and finally + + An open development model ([25]see below) for the development + process. + These three differences will work together to result in a more + useful compiler, a more stable compiler, a central compiler that + works for more people, a compiler that generates better code. + There are a lot of exciting compiler optimizations that have come + out. We want them in gcc. There are a lot of front ends out there + for gcc for languages like Fortran or Pascal. We want them easily + installable by users. After six years of working on gcc2, we've + come to see problems and limitations in the way gcc is + architected; it is time to address these again. + _____________________________________________________________ + What is an open development model? -With egcs, we are going to try a bazaar style[1] approach to its -development: We're going to be making snapshots publically available -to anyone who wants to try them; we're going to welcome anyone to join -the development mailing list. All of the discussions on the -development mailing list are available via the web. We're going to be -making releases with a much higher frequency than they have been made -in the past: We're shooting for three by the end of 1997. - -In addition to weekly snapshots of the egcs development sources, we -are going to look at making the sources readable from a CVS server by -anyone. We want to make it so external maintainers of parts of egcs -are able to commit changes to their part of egcs directly into the -sources without going through an intermediary. - -There have been many potential gcc developers who were not able to -participate in gcc development in the past. We these people to help in -any way they can; we ultimately want gcc to be the best compiler in the -world. - -A compiler is a complicated piece of software, there will still be -strong central maintainers who will reject patches, who will demand -documentation of implementations, and who will keep the level of -quality as high as it is today. Code that could use wider testing may -be intergrated--code that is simply ill-conceived won't be. - -egcs is not the first piece of software to use this open development -process; FreeBSD, the Emacs lisp repository, and Linux are a few -examples of the bazaar style of development. - -With egcs, we will be adding new features and optimizations at a -rate that has not been done since the creation of gcc2; these additions -will inevitably have a temporarily destabilizing effect. With the help -of developers working together with this bazaar style development, the -resulting stability and quality levels will be better than we've had -before. - -cathedral-vs-bazaar[1] - We've been discussing different development models a lot over the - past few months. The paper which started all of this introduced two - terms: A cathedral development model versus a bazaar - development model. The paper is written by Eric S. Raymond, it is - called `` http://locke.ccil.org/~esr/writings/cathedral.html" The - Cathedral and the Bazaar''. The paper is a useful starting point - for discussions. - - - + With egcs, we are going to try a bazaar style[26][1] approach to + its development: We're going to be making snapshots publicly + available to anyone who wants to try them; we're going to welcome + anyone to join the development mailing list. All of the + discussions on the development mailing list are available via the + web. We're going to be making releases with a much higher + frequency than they have been made in the past: We're shooting for + three by the end of 1997. + In addition to weekly snapshots of the egcs development sources, + we are going to look at making the sources readable from a CVS + server by anyone. We want to make it so external maintainers of + parts of egcs are able to commit changes to their part of egcs + directly into the sources without going through an intermediary. + There have been many potential gcc developers who were not able to + participate in gcc development in the past. We these people to + help in any way they can; we ultimately want gcc to be the best + compiler in the world. + A compiler is a complicated piece of software, there will still be + strong central maintainers who will reject patches, who will + demand documentation of implementations, and who will keep the + level of quality as high as it is today. Code that could use wider + testing may be intergrated--code that is simply ill-conceived + won't be. + egcs is not the first piece of software to use this open + development process; FreeBSD, the Emacs lisp repository, and Linux + are a few examples of the bazaar style of development. + With egcs, we will be adding new features and optimizations at a + rate that has not been done since the creation of gcc2; these + additions will inevitably have a temporarily destabilizing effect. + With the help of developers working together with this bazaar + style development, the resulting stability and quality levels will + be better than we've had before. + + [1] We've been discussing different development models a lot over + the past few months. The paper which started all of this introduced + two terms: A cathedral development model versus a bazaar + development model. The paper is written by Eric S. Raymond, it is + called ``[27]The Cathedral and the Bazaar''. The paper is a useful + starting point for discussions. + _____________________________________________________________ + +Releases and Forking? + + Some folks have questioned whether or not making releases is + consistent with the goals of the egcs project and whether or not + making releases is a fork from gcc2. + +The egcs project has several goals, including: + + * Experimenting with a new development model, release process and + release packaging, + + * Using the new development model to accelerate development of new + features, optimizations, etc for future inclusion in gcc, + + * Providing high quality releases to the public. + +An egcs release is a copy of the egcs sources that the developers have +tested and are believed to be suitable for wider scale use and testing. + +Making releases of stable, tested sources is both a goal and a means by +which we hope to achieve other goals of the egcs project. + +The existence of a stable tested release allows egcs to be more thoroughly +used and tested by a wider audience than is capable of testing snapshots. +The expanded audience provides developers with critical feedback in a +timely manner, which is beneficial to GCC as a whole and is consistent with +the stated goals of egcs. + +The gcc maintainers are encouraged to migrate tested fixes and new features +from egcs into gcc at their discretion. egcs maintainers are willing to +assist the gcc maintainers as time permits. egcs periodically merges in +changes from gcc into the egcs sources. + +What will keep egcs from becoming a fork is cooperation between the +developers of gcc and egcs. + +We don't see this situation as significantly different than other projects +that make releases based on some version of the gcc sources (Cygnus, g77, +etc). All the code is still available for inclusion in gcc at the discretion +of the gcc maintainers. + _____________________________________________________________ + bits/libc-lock.h: No such file or directory -egcs includes a tightly integrated libio and libstdc++ implementation which -can cause problems on hosts which have libio integrated into their C library -(most notably Linux). - -We believe that we've solved the major technical problems for the most -common versions of libc found on Linux systems. However, some versions -of Linux use pre-release versions of glibc2, which egcs has trouble detecting -and correctly handling. - -If you're using one of these pre-release versions of glibc2, you may get -a message "bits/libc-lock.h: No such file or directory" when building egcs. -Unfortunately, to fix this problem you will need to update your C library to -glibc2.0.5c. - -Late breaking news: we may have at least a partial solution for these -problems. So this FAQ entry may no longer be needed. - + This entry should be obsolete, egcs should handle these beta + versions of glibc2 correctly. + egcs includes a tightly integrated libio and libstdc++ + implementation which can cause problems on hosts which have libio + integrated into their C library (most notably Linux). + We believe that we've solved the major technical problems for the + most common versions of libc found on Linux systems. However, some + versions of Linux use pre-release versions of glibc2, which egcs + has trouble detecting and correctly handling. + If you're using one of these pre-release versions of glibc2, you + may get a message "bits/libc-lock.h: No such file or directory" + when building egcs. Unfortunately, to fix this problem you will + need to update your C library to glibc2.0.5c. + _____________________________________________________________ + `_IO_stdfile_0_lock' was not declared in this scope -If you get this error, it means either egcs incorrectly guessed what version -of libc is installed on your linux system, or you incorrectly specified a -version of glibc when configuring egcs. - -If you did not provide a target name when configuring egcs, then you've -found a bug which needs to be reported. If you did provide a target name at -configure time, then you should reconfigure without specifying a target name. - + If you get this error, it means either egcs incorrectly guessed + what version of libc is installed on your linux system, or you + incorrectly specified a version of glibc when configuring egcs. + If you did not provide a target name when configuring egcs, then + you've found a bug which needs to be reported. If you did provide + a target name at configure time, then you should reconfigure + without specifying a target name. + _____________________________________________________________ + Problems building the Fortran compiler -The Fortran front end can not be built with most vendor compilers; it must -be built with gcc. As a result, you may get an error if you do not follow -the install instructions carefully. - -In particular, instead of using "make" to build egcs, you should use -"make bootstrap" if you are building a native compiler or "make cross" -if you are building a cross compiler. - -It has also been reported that the Fortran compiler can not be built -on Red Hat 4.X linux for the Alpha. Fixing this may require upgrading -binutils or to Red Hat 5.0; we'll provide more information as it becomes -available. - + The Fortran front end can not be built with most vendor compilers; + it must be built with gcc. As a result, you may get an error if + you do not follow the install instructions carefully. + In particular, instead of using "make" to build egcs, you should + use "make bootstrap" if you are building a native compiler or + "make cross" if you are building a cross compiler. + It has also been reported that the Fortran compiler can not be + built on Red Hat 4.X linux for the Alpha. Fixing this may require + upgrading binutils or to Red Hat 5.0; we'll provide more + information as it becomes available. + _____________________________________________________________ + Problems building on MIPS platforms -egcs requires the use of GAS on all versions of Irix, except Irix 6 due -to limitations in older Irix assemblers. - Either of these messages indicates that you are using the MIPS assembler -when instead you should be using GAS. + egcs requires the use of GAS on all versions of Irix, except Irix + 6 due to limitations in older Irix assemblers. + Either of these messages indicates that you are using the MIPS + assembler when instead you should be using GAS. as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal .4byte $LECIE1-$LSCIE1 as0: Error: ./libgcc2.c, line 1:malformed statement - - - - as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression + _____________________________________________________________ + + as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol i +n expression .word $LECIE1-$LSCIE1 - - For Irix 6, you should use the native assembler as GAS is not supported -on Irix 6. - - + For Irix 6, you should use the native assembler as GAS is not + supported on Irix 6. + _____________________________________________________________ + Problems with exception handling on x86 platforms -If you are using the GNU assembler (aka gas) on an x86 platform and -exception handling is not working correctly, then odds are you're using a -buggy assembler. - -We recommend binutils-2.8.0.1.15 or newer. -"ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz binutils-2.8.0.1.15 source -ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz binutils-2.8.0.1.15 x86 binary for libc5 -ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz binutils-2.8.0.1.15 x86 binary for glibc2 -Or, you can try a -ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz binutils snapshot; however, be aware that the binutils snapshot is untested -and may not work (or even build). Use it at your own risk. - + If you are using the GNU assembler (aka gas) on an x86 platform + and exception handling is not working correctly, then odds are + you're using a buggy assembler. + We recommend binutils-2.8.1.0.15 or newer. + [28]binutils-2.8.1.0.15 source + [29]binutils-2.8.1.0.15 x86 binary for libc5 + [30]binutils-2.8.1.0.15 x86 binary for glibc2 Or, you can try a + [31]binutils snapshot; however, be aware that the binutils + snapshot is untested and may not work (or even build). Use it at + your own risk. + _____________________________________________________________ + Bootstrap comparison failures on HPs -If you bootstrap the compiler on hpux10 using the HP assembler instead of -gas, every file will fail the comparison test. - -The HP asembler inserts timestamps into object files it creates, causing -every file to be different. The location of the timestamp varies for each -object file, so there's no real way to work around this mis-feature. - -Odds are your compiler is fine, but there's no way to be certain. - -If you use GAS on HPs, then you will not run into this problem because -GAS never inserts timestamps into object files. For this and various other -reasons we highly recommend using GAS on HPs. - + If you bootstrap the compiler on hpux10 using the HP assembler + instead of gas, every file will fail the comparison test. + The HP asembler inserts timestamps into object files it creates, + causing every file to be different. The location of the timestamp + varies for each object file, so there's no real way to work around + this mis-feature. + Odds are your compiler is fine, but there's no way to be certain. + If you use GAS on HPs, then you will not run into this problem + because GAS never inserts timestamps into object files. For this + and various other reasons we highly recommend using GAS on HPs. + _____________________________________________________________ + Bootstrap loops rebuilding cc1 over and over -When building egcs, the build process loops rebuilding cc1 over and -over again. This happens on mips-sgi-irix5.2, and possibly other platforms. - -This is probably a bug somewhere in the egcs Makefile. Until we find and -fix this bug we recommend you use GNU make instead of vendor supplied make -programs. - + When building egcs, the build process loops rebuilding cc1 over + and over again. This happens on mips-sgi-irix5.2, and possibly + other platforms. + This is probably a bug somewhere in the egcs Makefile. Until we + find and fix this bug we recommend you use GNU make instead of + vendor supplied make programs. + _____________________________________________________________ + Dynamic linker is unable to find GCC libraries -This problem manifests itself by programs not finding shared libraries -they depend on when the programs are started. Note this problem often manifests -itself with failures in the libio/libstdc++ tests after configuring with ---enable-shared and building egcs. - -GCC does not specify a runpath so that the dynamic linker can find dynamic -libraries at runtime. - -The short explaination is that if you always pass a -R option to the -linker, then your programs become dependent on directories which -may be NFS mounted, and programs may hang unnecessarily when an -NFS server goes down. - -The problem is not programs that do require the directories; those -programs are going to hang no matter what you do. The problem is -programs that do not require the directories. - -SunOS effectively always passed a -R option for every -L option; -this was a bad idea, and so it was removed for Solaris. We should -not recreate it. - + This problem manifests itself by programs not finding shared + libraries they depend on when the programs are started. Note this + problem often manifests itself with failures in the + libio/libstdc++ tests after configuring with --enable-shared and + building egcs. + GCC does not specify a runpath so that the dynamic linker can find + dynamic libraries at runtime. + The short explaination is that if you always pass a -R option to + the linker, then your programs become dependent on directories + which may be NFS mounted, and programs may hang unnecessarily when + an NFS server goes down. + The problem is not programs that do require the directories; those + programs are going to hang no matter what you do. The problem is + programs that do not require the directories. + SunOS effectively always passed a -R option for every -L option; + this was a bad idea, and so it was removed for Solaris. We should + not recreate it. + _____________________________________________________________ + Unable to run the testsuite -If you get a message about unable to find "standard.exp" when trying to -run the egcs testsuites, then your dejagnu is too old to run the egcs tests. -You will need to get a newer version of dejagnu; we've made a -<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz"> -dejagnu snapshot available until a new version of dejagnu can be released. - + If you get a message about unable to find "standard.exp" when + trying to run the egcs testsuites, then your dejagnu is too old to + run the egcs tests. You will need to get a newer version of + dejagnu; we've made a [32]dejagnu snapshot available until a new + version of dejagnu can be released. + _____________________________________________________________ + How to build a cross compiler - Building cross compilers is a rather complex undertaking because they -usually need additional software (cross assembler, cross linker, target -libraries, target include files, etc). - - We recommend reading the <a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1"> -crossgcc FAQ for information about building cross compilers. - - If you have all the pieces available, then `make cross' should build a -cross compiler. `make LANGUAGES="c c++" install'will install the cross -compiler. - - Note that if you're trying to build a cross compiler in a tree which -includes binutils-2.8 in addition to egcs, then you're going to need to -make a couple minor tweaks so that the cross assembler, linker and -nm utilities will be found. - -binutils-2.8 builds those files as gas.new, ld.new and nm.new; egcs gcc -looks for them using gas-new, ld-new and nm-new, so you may have to arrange -for any symlinks which point to <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 diff --git a/INSTALL/FINALINSTALL b/INSTALL/FINALINSTALL index 5d893c563e0..5508135a2ad 100644 --- a/INSTALL/FINALINSTALL +++ b/INSTALL/FINALINSTALL @@ -1,19 +1,26 @@ -Final install egcs-1.0 -Now that egcs has been built and tested, you can install it with -`cd objdir; make install' for a native compiler or -`cd objdir; make install LANGUAGES="c c++"' for a cross compiler -(note installing cross compilers will be easier in the next release!). + Final install egcs-1.0.1 + + Now that egcs has been built and tested, you can install it with `cd + objdir; make install' for a native compiler or `cd objdir; make + install LANGUAGES="c c++"' for a cross compiler (note installing cross + compilers will be easier in the next release!). + + That step completes the installation of egcs; user level binaries can + be found in prefix/bin where prefix is the value you specified with + the --prefix to configure (or /usr/local by default). + + If you don't mind, please send egcs@cygnus.com a short mail message + indicating that you successfully built and installed egcs. Include the + output from running srcdir/config.guess. + + If you find a bug in egcs, please report it to + [1]egcs-bugs@cygnus.com. + + _________________________________________________________________ + + Last modified on Jan 2, 1998. +References -That step completes the installation of egcs; user level binaries can -be found in prefix/bin where prefix is the value you specified -with the --prefix to configure (or /usr/local by default). - -If you don't mind, please send egcs@cygnus.com a short mail message -indicating that you successfully built and installed egcs. Include -the output from running srcdir/config.guess. - -If you find a bug in egcs, please report it to egcs-bugs@cygnus.com - -Last modified on December 2, 1997. + 1. mailto:egcs-bugs@cygnus.com diff --git a/INSTALL/INDEX b/INSTALL/INDEX index c651389f3f1..2abbe5979de 100644 --- a/INSTALL/INDEX +++ b/INSTALL/INDEX @@ -1,34 +1,46 @@ -Installing egcs-1.0 - -This document describes the generic installation procedure for egcs as -well as detailing some target specific installation instructions for egcs. - -egcs includes several components that previously were separate distributions -with their own installation instructions. This document supercedes all -package specific installation instructions. We provide the component specific -installation information in the source distribution for historical reference -purposes only. - -We recommend you read the entire generic installation instructions as -well as any target specific installation instructions before you proceed -to configure, build, test and install egcs. - -If something goes wrong in the configure, build, test or install -procedures, first double check that you followed the generic and target -specific installation instructions carefully. Then check the EGCS FAQ -(FAQ) to see if your problem is covered before you file a bug report. - -The installation procedure is broken into four steps. - - - Configure see CONFIGURE - Build see BUILD - Test see TEST - Final Install see FINALINSTALL - - -Before starting the build/install procedure please browse the -host/target specific installation notes (SPECIFIC). - -Last modified on December 2, 1997. + Installing egcs-1.0.1 + + This document describes the generic installation procedure for egcs as + well as detailing some target specific installation instructions for + egcs. + + egcs includes several components that previously were separate + distributions with their own installation instructions. This document + supercedes all package specific installation instructions. We provide + the component specific installation information in the source + distribution for historical reference purposes only. + + We recommend you read the entire generic installation instructions as + well as any target specific installation instructions before you + proceed to configure, build, test and install egcs. + + If something goes wrong in the configure, build, test or install + procedures, first double check that you followed the generic and + target specific installation instructions carefully. Then check the + [1]FAQ to see if your problem is covered before you file a bug report. + + The installation procedure is broken into four steps. + * [2]configure + * [3]build + * [4]test (optional) + * [5]install + + Before starting the build/install procedure please browse the + [6]host/target specific installation notes. + _________________________________________________________________ + + [7]Return to the egcs home page + _________________________________________________________________ + + Last modified on Jan 2, 1998. + +References + + 1. file://localhost/home/law/INSTALL/faq.html + 2. file://localhost/home/law/INSTALL/configure.html + 3. file://localhost/home/law/INSTALL/build.html + 4. file://localhost/home/law/INSTALL/test.html + 5. file://localhost/home/law/INSTALL/finalinstall.html + 6. file://localhost/home/law/INSTALL/specific.html + 7. file://localhost/home/law/index.html diff --git a/INSTALL/SPECIFIC b/INSTALL/SPECIFIC index 386836b83d9..5cddc5c7c60 100644 --- a/INSTALL/SPECIFIC +++ b/INSTALL/SPECIFIC @@ -1,106 +1,122 @@ -Host/Target specific installation notes for egcs-1.0 -alpha*-*-* -No specific installation needs/instructions. - - -i?86-*-linux* -You will need binutils-2.8.1.0.15 or newer for exception handling to work. - -i?86-*-sco3.2v5* -The SCO assembler is currently required. The GNU assembler is not up -to the task of switching between ELF and COFF at runtime. - -Unlike various prereleases of GCC, that used '-belf' and defaulted to -COFF, you must now use the '-melf' and '-mcoff' flags to toggle between -the two object file formats. ELF is now the default. - -Look in gcc/config/i386/sco5.h (search for "messy") for additional -OpenServer-specific flags. - - - -hppa*-hp-hpux* -We highly recommend using gas/binutils-2.8 on all hppa platforms; you -may encounter a variety of problems when using the HP assembler. - -hppa*-hp-hpux9 -The HP assembler has major problems on this platform. We've tried to work -around the worst of the problems. However, those workarounds may be causing -linker crashes in some circumstances; the workarounds also probably prevent -shared libraries from working. Use the GNU assembler to avoid these problems. - -The configuration scripts for egcs will also trigger a bug in the hpux9 -shell. To avoid this problem set CONFIG_SHELL to /bin/ksh and SHELL to -/bin/ksh in your environment. - -hppa*-hp-hpux10 -For hpux10.20, we highly recommend you pick up the latest sed -patch from HP. HP has two sites which provide patches free of charge. - -http://us-support.external.hp.com for US, Canada, Asia-Pacific, and -Latin-America -http://europe-support.external.hp.com for Europe - -Retrieve patch PHCO_12862. - -The HP assembler on these systems is much better than the hpux9 assembler, -but still has some problems. Most notably the assembler inserts timestamps -into each object file it creates, causing the 3-stage comparison test to fail -during a "make bootstrap". You should be able to continue by saying "make all" -after getting the failure from "make bootstrap". - -m68k-*-nextstep* -You absolutely must use GNU sed and GNU make on this platform. - -If you try to build the integrated C++ & C++ runtime libraries on this system -you will run into trouble with include files. The way to get around this is -to use the following sequence. Note you must have write permission to -prefix for this sequence to work. - -cd objdir -make all-texinfo all-bison all-byacc all-binutils all-gas all-ld -cd gcc -make bootstrap -make install-headers-tar -cd .. -make bootstrap3 - -m68k-sun-sunos4.1.1 -It is reported that you may need the GNU assembler on this platform. - -mips*-sgi-irix4 -mips*-sgi-irix5 -You must use GAS on these platforms, the native assembler can not handle the -code for exception handling support on this platform. - -These systems don't have ranlib, which various components in egcs need; you -should be able to avoid this problem by installing GNU binutils, which includes -a functional ranlib for this system. - -You may get the following warning on irix4 platforms, it can be safely -ignored. + Host/Target specific installation notes for egcs-1.0.1 + + alpha*-*-* + No specific installation needs/instructions. + + i?86-*-linux* + You will need binutils-2.8.1.0.15 or newer for exception handling to + work. + + i?86-*-sco3.2v5* + The SCO assembler is currently required. The GNU assembler is not up + to the task of switching between ELF and COFF at runtime. + Unlike various prereleases of GCC, that used '-belf' and defaulted to + COFF, you must now use the '-melf' and '-mcoff' flags to toggle + between the two object file formats. ELF is now the default. + Look in gcc/config/i386/sco5.h (search for "messy") for additional + OpenServer-specific flags. + + i?86-pc-solaris* + You'll need a patch to fix an egcs bug on this platform. [1]x86 + solaris patch + + hppa*-hp-hpux* + We highly recommend using gas/binutils-2.8 on all hppa platforms; you + may encounter a variety of problems when using the HP assembler. + + hppa*-hp-hpux9 + The HP assembler has major problems on this platform. We've tried to + work around the worst of the problems. However, those workarounds may + be causing linker crashes in some circumstances; the workarounds also + probably prevent shared libraries from working. Use the GNU assembler + to avoid these problems. + The configuration scripts for egcs will also trigger a bug in the + hpux9 shell. To avoid this problem set CONFIG_SHELL to /bin/ksh and + SHELL to /bin/ksh in your environment. + + hppa*-hp-hpux10 + For hpux10.20, we highly recommend you pick up the latest sed patch + from HP. HP has two sites which provide patches free of charge. + [2]US, Canada, Asia-Pacific, and Latin-America + [3]Europe + + Retrieve patch PHCO_12862. + + The HP assembler on these systems is much better than the hpux9 + assembler, but still has some problems. Most notably the assembler + inserts timestamps into each object file it creates, causing the + 3-stage comparison test to fail during a "make bootstrap". You should + be able to continue by saying "make all" after getting the failure + from "make bootstrap". + + m68k-*-nextstep* + You absolutely must use GNU sed and GNU make on this platform. + + If you try to build the integrated C++ & C++ runtime libraries on this + system you will run into trouble with include files. The way to get + around this is to use the following sequence. Note you must have write + permission to prefix for this sequence to work. + + cd objdir + make all-texinfo all-bison all-byacc all-binutils all-gas all-ld + cd gcc + make bootstrap + make install-headers-tar + cd .. + make bootstrap3 + + m68k-sun-sunos4.1.1 + It is reported that you may need the GNU assembler on this platform. + + mips*-sgi-irix4 + mips*-sgi-irix5 + You must use GAS on these platforms, the native assembler can not + handle the code for exception handling support on this platform. + + These systems don't have ranlib, which various components in egcs + need; you should be able to avoid this problem by installing GNU + binutils, which includes a functional ranlib for this system. + + You may get the following warning on irix4 platforms, it can be safely + ignored. warning: foo.o does not have gp tables for all its sections. -mips*-sgi-irix6 -You must not use GAS on irix6 platforms; doing so will only cause problems. - -These systems don't have ranlib, which various components in egcs need; you -should be able to avoid this problem by making a dummy script called ranlib -which just exits with zero status and placing it in your path. - -rs6000-ibm-aix* -powerpc-ibm-aix* -At least one person as reported problems with older versions of gnu-make on -this platform. make-3.76 is reported to work correctly. - -powerpc-*-linux-gnu* -You will need binutils-2.8.1.0.17 from ftp://ftp.yggdrasil.com/private/hjl for -a working egcs. It is strongly recommended to recompile binutils with egcs -if you initially built it with gcc-2.7.2.*. - - -exception handling -XXX Linux stuff -Last modified on December 2, 1997. + mips*-sgi-irix6 + You must not use GAS on irix6 platforms; doing so will only cause + problems. + + These systems don't have ranlib, which various components in egcs + need; you should be able to avoid this problem by making a dummy + script called ranlib which just exits with zero status and placing it + in your path. + + rs6000-ibm-aix* + powerpc-ibm-aix* + At least one person as reported problems with older versions of + gnu-make on this platform. make-3.76 is reported to work correctly. + + powerpc-*-linux-gnu* + You will need [4]binutils-2.8.1.0.17 for a working egcs. It is + strongly recommended to recompile binutils with egcs if you initially + built it with gcc-2.7.2.*. + + sparc-unkonwn-linux-gnulibc1 + It has been reported that you might need binutils-2.8.1.0.17 for this + platform too. [5]binutils-2.8.1.0.17 + + exception handling + + XXX Linux stuff -k encaps stuff + _________________________________________________________________ + + Last modified on Jan 2, 1998. + +References + + 1. http://www.cygnus.com/egcs/faq.html#x86solaris + 2. http://us-support.external.hp.com/ + 3. http://europe-support.external.hp.com/ + 4. ftp://ftp.yggdrasil.com/private/hjl + 5. ftp://ftp.yggdrasil.com/private/hjl diff --git a/INSTALL/TEST b/INSTALL/TEST index 749204571ca..66b5f3c2f3c 100644 --- a/INSTALL/TEST +++ b/INSTALL/TEST @@ -1,28 +1,34 @@ -Testing egcs-1.0 -Before you install egcs, you might wish to run the egcs testsuite; this -step is optional and may require you to download additional software. + Testing egcs-1.0.1 + + Before you install egcs, you might wish to run the egcs testsuite; + this step is optional and may require you to download additional + software. + + First, you must have downloaded the egcs testsuites; the full + distribution contains testsuites. If you downloaded the "core" + compiler plus any front ends, then you do not have the testsuites. You + can download the testsuites from the same site where you downloaded + the core distribution and language front ends. + + Second, you must have a new version of dejagnu on your system; + dejagnu-1.3 will not work. We have made a [1]dejagnu snapshot + available in ftp.cygnus.com:/pub/egcs/infrastructure until a new + version of dejagnu can be released. + + Assuming you've got the testsuites unpacked and have installed an + appropriate dejagnu, you can run the testsuite with "cd objdir; make + -k check". This may take a long time. Go get some lunch. + + The testing process will try to test as many components in the egcs + distrubution as possible, including the C, C++ and Fortran compiler as + well as the C++ runtime libraries. + + How to interpret test results XXX. + _________________________________________________________________ + + Last modified on Jan 2, 1998. -First, you must have downloaded the egcs testsuites; the full distribution -contains testsuites. If you downloaded the "core" compiler plus any front -ends, then you do not have the testsuites. You can download the testsuites -from the same site where you downloaded the core distribution and language -front ends. +References -Second, you must have a new version of dejagnu on your system; dejagnu-1.3 -will not work. We have made a dejagnu snapshot -ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz -dejagnu snapshot available in ftp.cygnus.com:/pub/egcs/infrastructure until -a new version of dejagnu can be released. - -Assuming you've got the testsuites unpacked and have installed an appropriate -dejagnu, you can run the testsuite with "cd objdir; make -k check". -This may take a long time. Go get some lunch. - -The testing process will try to test as many components in the egcs -distrubution as possible, including the C, C++ and Fortran compiler as -well as the C++ runtime libraries. - - How to interpret test results XXX. - -Last modified on December 2, 1997. + 1. ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz diff --git a/INSTALL/build.html b/INSTALL/build.html index 750b2c4a5f2..f333640496c 100644 --- a/INSTALL/build.html +++ b/INSTALL/build.html @@ -1,9 +1,9 @@ <html> <head> -<title>Building egcs-1.0 </title> +<title>Building egcs-1.0.1 </title> </head> <body bgcolor="white"> -<h1 align="center">Building egcs-1.0</h1> +<h1 align="center">Building egcs-1.0.1</h1> <p>Now that egcs is configured, you are ready to build the compiler and runtime libraries. @@ -60,7 +60,7 @@ following steps: <p> <hr> -<i>Last modified on December 2, 1997.</i> +<i>Last modified on Jan 2, 1998.</i> </body> </html> diff --git a/INSTALL/configure.html b/INSTALL/configure.html index ff26b384b9c..2e32d6943da 100644 --- a/INSTALL/configure.html +++ b/INSTALL/configure.html @@ -1,9 +1,9 @@ <html> <head> -<title>Configuring egcs-1.0 </title> +<title>Configuring egcs-1.0.1 </title> </head> <body bgcolor="white"> -<h1 align="center">Configuring egcs-1.0</h1> +<h1 align="center">Configuring egcs-1.0.1</h1> <p>Like most GNU software, egcs must be configured before it can be built. This document attempts to describe the recommended configuration procedure @@ -116,7 +116,7 @@ that each <tt>--with</tt> option has a corresponding <tt>--without</tt> option. <p> <hr> -<i>Last modified on December 2, 1997.</i> +<i>Last modified on Jan 2, 1998.</i> </body> </html> diff --git a/INSTALL/faq.html b/INSTALL/faq.html index cbc82dafe12..1a43a77e00d 100644 --- a/INSTALL/faq.html +++ b/INSTALL/faq.html @@ -8,6 +8,7 @@ <ol> <li><a href="#gcc-2-diff">How is egcs be different from gcc2?</a> <li><a href="#open-development">What is an open development model?</a> + <li><a href="#release-fork">Releases and Forking</a> <li><a href="#libc-lock">bits/libc-lock.h: No such file or directory</a> <li><a href="#morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a> <li><a href="#fortran">Problems building the Fortran compiler</a> @@ -25,6 +26,10 @@ <li><a href="#memexhausted">Virtual memory exhausted</a> <li><a href="#gas">GCC can not find GAS</a> <li><a href="#rh5.0">egcs does not work on Red Hat 5.0</a> + <li><a href="#x86solaris">Unable to bootstrap on x86 Solaris2.{5,6}</a> + <li><a href="#windows">EGCS with Windows</a> + <li><a href="#environ">cpp: Usage:... Error<a> + <li><a href="#kde">EGCS will not build KDE<a> </ol> @@ -71,7 +76,7 @@ time to address these again. <p>With egcs, we are going to try a bazaar style<a href="#cathedral-vs-bazaar"><b>[1]</b></a> approach to its -development: We're going to be making snapshots publically available +development: We're going to be making snapshots publicly available to anyone who wants to try them; we're going to welcome anyone to join the development mailing list. All of the discussions on the development mailing list are available via the web. We're going to be @@ -118,9 +123,54 @@ before. for discussions. </blockquote> +<hr> +<h2><a name="release-fork">Releases and Forking?</a></h2> +<p>Some folks have questioned whether or not making releases is consistent +with the goals of the egcs project and whether or not making releases is +a fork from gcc2. + +<pre> +The egcs project has several goals, including: + + * Experimenting with a new development model, release process and + release packaging, + + * Using the new development model to accelerate development of new + features, optimizations, etc for future inclusion in gcc, + + * Providing high quality releases to the public. + +An egcs release is a copy of the egcs sources that the developers have +tested and are believed to be suitable for wider scale use and testing. + +Making releases of stable, tested sources is both a goal and a means by +which we hope to achieve other goals of the egcs project. + +The existence of a stable tested release allows egcs to be more thoroughly +used and tested by a wider audience than is capable of testing snapshots. +The expanded audience provides developers with critical feedback in a +timely manner, which is beneficial to GCC as a whole and is consistent with +the stated goals of egcs. + +The gcc maintainers are encouraged to migrate tested fixes and new features +from egcs into gcc at their discretion. egcs maintainers are willing to +assist the gcc maintainers as time permits. egcs periodically merges in +changes from gcc into the egcs sources. + +What will keep egcs from becoming a fork is cooperation between the +developers of gcc and egcs. + +We don't see this situation as significantly different than other projects +that make releases based on some version of the gcc sources (Cygnus, g77, +etc). All the code is still available for inclusion in gcc at the discretion +of the gcc maintainers. +</pre> <hr> <h2><a name="libc-lock">bits/libc-lock.h: No such file or directory</a></h2> +<p>This entry should be obsolete, egcs should handle these beta versions of +glibc2 correctly. + <p>egcs includes a tightly integrated libio and libstdc++ implementation which can cause problems on hosts which have libio integrated into their C library (most notably Linux). @@ -135,9 +185,6 @@ a message "bits/libc-lock.h: No such file or directory" when building egcs. Unfortunately, to fix this problem you will need to update your C library to glibc2.0.5c. -<p>Late breaking news: we may have at least a partial solution for these -problems. So this FAQ entry may no longer be needed. - <hr> <h2><a name="morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a></h2> <p>If you get this error, it means either egcs incorrectly guessed what version @@ -194,10 +241,10 @@ on Irix 6. exception handling is not working correctly, then odds are you're using a buggy assembler. -<p>We recommend binutils-2.8.0.1.15 or newer. -<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz"> binutils-2.8.0.1.15 source</a> -<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz"> binutils-2.8.0.1.15 x86 binary for libc5</a> -<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz"> binutils-2.8.0.1.15 x86 binary for glibc2</a> +<p>We recommend binutils-2.8.1.0.15 or newer. +<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz"> binutils-2.8.1.0.15 source</a> +<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz"> binutils-2.8.1.0.15 x86 binary for libc5</a> +<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz"> binutils-2.8.1.0.15 x86 binary for glibc2</a> Or, you can try a <a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz"> binutils snapshot</a>; however, be aware that the binutils snapshot is untested and may not work (or even build). Use it at your own risk. @@ -254,7 +301,7 @@ not recreate it. <p>If you get a message about unable to find "standard.exp" when trying to run the egcs testsuites, then your dejagnu is too old to run the egcs tests. You will need to get a newer version of dejagnu; we've made a -<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz"> +<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz"> dejagnu snapshot</a> available until a new version of dejagnu can be released. <hr> @@ -320,6 +367,13 @@ for the "g++", "c++" and "g77" compiler drivers. you may not be able to build the kernel because objdump does not understand the "-k" switch. The solution for this problem is to remove /usr/bin/encaps. +<p>The reason you must remove /usr/bin/encaps is because it is an obsolete +program that was part of older binutils distributions; the Linux kernel's +Makefile looks for this program to decide if you have an old or a new +binutils. Problems occur if you installed a new binutils but haven't +removed encaps, because the Makefile thinks you have the old one. So zap +it; trust us, you won't miss it. + <p>You may get an internal compiler error compiling process.c in newer versions of the Linux kernel on x86 machines. This is a bug in an asm statement in process.c, not a bug in egcs. XXX How to fix?!? @@ -329,7 +383,7 @@ statement in process.c, not a bug in egcs. XXX How to fix?!? _X11TransSocketUNIXConnect: Can't connect: errno = 111 </pre> -<p>It's a kernel bug. The function sys_iopl in arch/i386/kernel/process.c +<p>It's a kernel bug. The function sys_iopl in arch/i386/kernel/ioport.c does an illegal hack which used to work but is now broken since GCC optimizes more aggressively . The newer 2.1.x kernels already have a fix which should also work in 2.0.32. @@ -350,16 +404,103 @@ will need to specify -Wno-return-type to turn it off. <p>Some configurations like irix4, irix5, hpux* require the use of the GNU assembler intead of the system assembler. To ensure that egcs finds the GNU assembler, you should configure the GNU assembler with the same --prefix -option as you used for egcs. Then build & install the GNU assembler. +option as you used for egcs. Then build & install the GNU assembler. After +the GNU assembler has been installed, proceed with building egcs. <hr> <h2> <a name="rh5.0">egcs does not work on Red Hat 5.0</a></h2> -<p> egcs does not currently work with Red Hat 5.0; we'll update this -entry with more information as it becomes available. +<p> This entry is obsolete with the release of egcs-1.0.1 which should +handle Red Hat 5.0 correctly. + +<p> egcs-1.0 does not currently work with Red Hat 5.0 on some platforms; we'll +update this entry with more information as it becomes available. + +<p> You may want to try this +<a href="http://www.cygnus.com/ml/egcs/1997-Dec/0594.html"> proposed patch</a> +for Red Hat 5.0. Please let us know if you use this patch and whether or +not it works. + +<hr> +<h2> <a name="x86solaris">Unable to bootstrap on x86 Solaris 2.{5,6}</a></h2> +<p> This entry is obsolete with the release of egcs-1.0.1 which should +handle x86 Solaris systems correctly. + +<p>This patch should fix the problem + +<pre> +Index: t-sol2 +=================================================================== +RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/t-sol2,v +retrieving revision 1.2 +diff -c -3 -p -r1.2 t-sol2 +*** t-sol2 1997/09/04 23:54:04 1.2 +--- t-sol2 1997/12/04 07:19:07 +*************** crtn.o: $(srcdir)/config/i386/sol2-cn.as +*** 31,36 **** + # to produce a shared library, but since we don't know ahead of time when + # we will be doing that, we just always use -fPIC when compiling the + # routines in crtstuff.c. + +! CRTSTUFF_T_CFLAGS = -fPIC + TARGET_LIBGCC2_CFLAGS = -fPIC +--- 31,40 ---- + # to produce a shared library, but since we don't know ahead of time when + # we will be doing that, we just always use -fPIC when compiling the + # routines in crtstuff.c. ++ # ++ # We must also enable optimization to avoid having any code appear after ++ # the call & alignment statement, but before we switch back to the ++ # .text section. + +! CRTSTUFF_T_CFLAGS = -fPIC -O2 + TARGET_LIBGCC2_CFLAGS = -fPIC +</pre> + +<hr> +<h2> <a name="windows">EGCS with Windows</a></h2> +<p>egcs does not currently support windows, either natively or with the +cygwin32 dll. However Mumit Khan has been working on supporting Windows +with egcs. You should check out his site if you're interested in Windows +support. +<a href="http://www.xraylith.wisc.edu/~khan/software/gnu-win32">GNU Win32 related projects</a> + +<hr> +<h2> <a name="environ">cpp: Usage:... Error</a></h2> +<p>If you get an error like this when building egcs (particularly when building +__mulsi3), then you likely have a problem with your environment variables. +<pre> +cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp +[switches] input output +</pre> + +<p>First look for an explicit '.' in either LIBRARY_PATH or GCC_EXEC_PREFIX +from your environment. If you do not find an explicit '.', look for +an empty pathname in those variables. Note that ':' at either the start +or end of these variables is an implicit '.' and will cause problems. + +<hr> +<h2> <a name="kde">EGCS will not build KDE</a></h2> +<p> Previous versions of g++ accepted (as a GNU extension) +constructor-arguments for the objects in an array of objects +dynamically allocated with new. Here's an example of this construct: + +<pre> + struct S { S(int); } + void f() { new S[3](6); } +</pre> + +<p>However, this construct is not allowed by the ANSI/ISO Standard, and +is no longer accepted by g++. + +<p> KDE uses such constructs and therefore will not build with egcs; note +patches are available to fix KDE. + + + <hr> <p><a href="index.html">Return to the egcs home page</a> -<p><i>Last modified: December 2, 1997</i> +<p><i>Last modified: Jan 2, 1998</i> </body> </html> diff --git a/INSTALL/finalinstall.html b/INSTALL/finalinstall.html index c7984f106a7..d0371a86bf9 100644 --- a/INSTALL/finalinstall.html +++ b/INSTALL/finalinstall.html @@ -1,9 +1,9 @@ <html> <head> -<title>Final install egcs-1.0 </title> +<title>Final install egcs-1.0.1 </title> </head> <body bgcolor="white"> -<h1 align="center">Final install egcs-1.0</h1> +<h1 align="center">Final install egcs-1.0.1</h1> <p>Now that egcs has been built and tested, you can install it with `cd <i>objdir</i>; make install' for a native compiler or @@ -24,7 +24,7 @@ the output from running <i>srcdir</i>/config.guess. <p> <hr> -<i>Last modified on December 2, 1997.</i> +<i>Last modified on Jan 2, 1998.</i> </body> </html> diff --git a/INSTALL/index.html b/INSTALL/index.html index ab4e4e4cb42..db59254a706 100644 --- a/INSTALL/index.html +++ b/INSTALL/index.html @@ -1,9 +1,9 @@ <html> <head> -<title>Installing egcs-1.0 </title> +<title>Installing egcs-1.0.1 </title> </head> <body bgcolor="white"> -<h1 align="center">Installing egcs-1.0</h1> +<h1 align="center">Installing egcs-1.0.1</h1> <p>This document describes the generic installation procedure for egcs as well as detailing some target specific installation instructions for egcs. @@ -21,7 +21,7 @@ to configure, build, test and install egcs. <p>If something goes wrong in the configure, build, test or install procedures, first double check that you followed the generic and target specific installation instructions carefully. Then check the -<a href="../faq.html">FAQ</a> to see if your problem is covered before you file +<a href="faq.html">FAQ</a> to see if your problem is covered before you file a bug report. <p>The installation procedure is broken into four steps. @@ -43,5 +43,5 @@ a bug report. </body> </html> <hr> -<i>Last modified on December 2, 1997.</i> +<i>Last modified on Jan 2, 1998.</i> diff --git a/INSTALL/specific.html b/INSTALL/specific.html index 89a81db3500..6faa1616080 100644 --- a/INSTALL/specific.html +++ b/INSTALL/specific.html @@ -1,9 +1,9 @@ <html> <head> -<title>Host/Target specific installation notes for egcs-1.0 </title> +<title>Host/Target specific installation notes for egcs-1.0.1 </title> </head> <body bgcolor="white"> -<h1 align="center">Host/Target specific installation notes for egcs-1.0</h1> +<h1 align="center">Host/Target specific installation notes for egcs-1.0.1</h1> <p><b>alpha*-*-*</b><br> No specific installation needs/instructions. @@ -23,14 +23,16 @@ the two object file formats. ELF is now the default. <br>Look in gcc/config/i386/sco5.h (search for "messy") for additional OpenServer-specific flags. +<p><b>i?86-pc-solaris*</b><br> +You'll need a patch to fix an egcs bug on this platform. +<a href="http://www.cygnus.com/egcs/faq.html#x86solaris"> x86 solaris patch</a> + <p><b>hppa*-hp-hpux*</b><br> We <b>highly</b> recommend using gas/binutils-2.8 on all hppa platforms; you may encounter a variety of problems when using the HP assembler. -XXX How to make sure gcc finds/uses gas. - <p><b>hppa*-hp-hpux9</b><br> The HP assembler has major problems on this platform. We've tried to work around the worst of the problems. However, those workarounds may be causing @@ -109,11 +111,17 @@ You will need a working egcs. It is strongly recommended to recompile binutils with egcs if you initially built it with gcc-2.7.2.*. +<p><b>sparc-unkonwn-linux-gnulibc1</b><br> +It has been reported that you might need binutils-2.8.1.0.17 for this +platform too. +<a href="ftp://ftp.yggdrasil.com/private/hjl">binutils-2.8.1.0.17</a> + <p> exception handling <p>XXX Linux stuff +-k encaps stuff <hr> -<i>Last modified on December 2, 1997.</i> +<i>Last modified on Jan 2, 1998.</i> </body> </html> diff --git a/INSTALL/test.html b/INSTALL/test.html index c77de859229..5e2d2fa58d6 100644 --- a/INSTALL/test.html +++ b/INSTALL/test.html @@ -1,9 +1,9 @@ <html> <head> -<title>Testing egcs-1.0 </title> +<title>Testing egcs-1.0.1 </title> </head> <body bgcolor="white"> -<h1 align="center">Testing egcs-1.0</h1> +<h1 align="center">Testing egcs-1.0.1</h1> <p>Before you install egcs, you might wish to run the egcs testsuite; this step is optional and may require you to download additional software. @@ -16,7 +16,7 @@ front ends. <p>Second, you must have a new version of dejagnu on your system; dejagnu-1.3 will not work. We have made a -<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz"> +<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz"> dejagnu snapshot</a> available in ftp.cygnus.com:/pub/egcs/infrastructure until a new version of dejagnu can be released. @@ -31,7 +31,7 @@ well as the C++ runtime libraries. <p> How to interpret test results XXX. <hr> -<i>Last modified on December 2, 1997.</i> +<i>Last modified on Jan 2, 1998.</i> </body> </html> diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 46407cb2943..ebaff2d7969 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,10 @@ +Fri Jan 2 23:40:09 1998 Jim Wilson (wilson@cygnus.com) + Jeffrey A Law (law@cygnus.com) + + * crtstuff.c (__frame_dummy): New function for irix6. + (__do_global_ctors): Call __frame_dummy for irix6. + * iris6.h (LINK_SPEC): Hide __frame_dummy too. + Wed Dec 24 23:03:42 1997 Jim Wilson (wilson@cygnus.com) * mips.c (mips_expand_epilogue): Emit blockage insn before call to diff --git a/gcc/config/mips/iris6.h b/gcc/config/mips/iris6.h index 86746d11e84..109546e60c2 100644 --- a/gcc/config/mips/iris6.h +++ b/gcc/config/mips/iris6.h @@ -1,5 +1,5 @@ /* Definitions of target machine for GNU compiler. Iris version 6. - Copyright (C) 1994, 1995, 1996 Free Software Foundation, Inc. + Copyright (C) 1994, 1995, 1996, 1998 Free Software Foundation, Inc. This file is part of GNU CC. @@ -542,5 +542,5 @@ do { \ %{!static: \ %{!shared: %{!non_shared: %{!call_shared: -call_shared -no_unresolved}}}} \ %{rpath} -init __do_global_ctors -fini __do_global_dtors \ -%{shared:-hidden_symbol __do_global_ctors,__do_global_dtors,__EH_FRAME_BEGIN__} \ +%{shared:-hidden_symbol __do_global_ctors,__do_global_dtors,__EH_FRAME_BEGIN__,__frame_dummy} \ -_SYSTYPE_SVR4 %{mabi=32: -32}%{mabi=n32: -n32}%{mabi=64: -64} %{!mabi*: -n32}" diff --git a/gcc/crtstuff.c b/gcc/crtstuff.c index 7e3c3edb25a..ef683a199d9 100644 --- a/gcc/crtstuff.c +++ b/gcc/crtstuff.c @@ -1,6 +1,6 @@ /* Specialized bits of code needed to support construction and destruction of file-scope objects in C++ code. - Copyright (C) 1991, 1994, 1995, 1996 Free Software Foundation, Inc. + Copyright (C) 1991, 1994, 1995, 1996, 1997 Free Software Foundation, Inc. Contributed by Ron Guilmette (rfg@monkeys.com). This file is part of GNU CC. @@ -257,6 +257,18 @@ __do_global_dtors () __deregister_frame_info (__EH_FRAME_BEGIN__); #endif } + +#ifdef EH_FRAME_SECTION_ASM_OP +/* Define a function here to call __register_frame. crtend.o is linked in + after libgcc.a, and hence can't call libgcc.a functions directly. That + can lead to unresolved function references. */ +void +__frame_dummy () +{ + static struct object object; + __register_frame_info (__EH_FRAME_BEGIN__, &object); +} +#endif #endif #endif /* defined(INIT_SECTION_ASM_OP) */ @@ -387,15 +399,13 @@ __do_global_ctors_aux () /* prologue goes in .text section */ /* This case is used by the Irix 6 port, which supports named sections but not an SVR4-style .init section. __do_global_ctors can be non-static in this case because we protect it with -hidden_symbol. */ -extern char __EH_FRAME_BEGIN__[]; static func_ptr __CTOR_END__[]; void __do_global_ctors () { func_ptr *p; #ifdef EH_FRAME_SECTION_ASM_OP - static struct object object; - __register_frame_info (__EH_FRAME_BEGIN__, &object); + __frame_dummy (); #endif for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--) (*p) (); diff --git a/gcc/gcc.1 b/gcc/gcc.1 index 4b6ccd3a2e4..10422c2ea03 100644 --- a/gcc/gcc.1 +++ b/gcc/gcc.1 @@ -20,10 +20,10 @@ .if n .sp .if t .sp 0.4 .. -.Id $Id: gcc.1,v 1.1.1.1 1997/08/11 15:57:07 law Exp $ +.Id $Id: gcc.1,v 1.1.1.1.2.1 1997/12/03 08:07:52 law Exp $ .TH GCC 1 "\*(Dt" "GNU Tools" "GNU Tools" .SH NAME -gcc, g++ \- GNU project C and C++ Compiler (egcs-1.0) +gcc, g++ \- GNU project C and C++ Compiler (egcs-1.0.1) .SH SYNOPSIS .B gcc .RI "[ " option " | " filename " ].\|.\|." diff --git a/gcc/gcc.texi b/gcc/gcc.texi index 99887cdd661..5072b86e1ef 100644 --- a/gcc/gcc.texi +++ b/gcc/gcc.texi @@ -148,7 +148,7 @@ original English. @sp 1 @c The version number appears twice more in this file. -@center for egcs-1.0 +@center for egcs-1.0.1 @page @vskip 0pt plus 1filll Copyright @copyright{} 1988, 89, 92, 93, 94, 95, 96 Free Software Foundation, Inc. diff --git a/gcc/version.c b/gcc/version.c index f04d3c87512..b91ba861425 100644 --- a/gcc/version.c +++ b/gcc/version.c @@ -1 +1 @@ -char *version_string = "egcs-2.90.22 971220 (egcs-1.01 beta)"; +char *version_string = "egcs-2.90.23 980102 (egcs-1.0.1 release)"; |