From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: egcs@cygnus.com, egcs-announce-outgoing@cygnus.com Cc: zing@cygnus.com Subject: Release Status Date: Thu, 30 Oct 1997 13:51:00 -0000 Message-id: <5419.878248382@hurl.cygnus.com> X-SW-Source: 1997-1998-old/msg00000.html As most of you know, we had hoped to get an initial EGCS release made by Sept 1997. It is now close to Nov 1997, so obviously we missed our target date. Without going into all the details, the problem has been part technical and part manpower shortage to deal with the technical issues. The good news is we believe we have cleared the major technical hurdles and the remaining issues should be fairly easily resolved. The delay has also given us the chance to install some significant C++ template improvements, Fortran performance improvements and add an integrated libio/libstdc++ which works with popular Linux systems. So, here is the outstanding issues that need to be resolved before the first release. * Fix the "NULL" problems on Linux. We believe this is the last hurdle to having a compiler & runtime libraries that work out of the box on the most popular Linux configurations. A prototype solution will be in the next snapshot. * Improved EH implementation. There are three issues that still need to be addressed before we are going to consider the EH implementation ready for the first egcs release. * Fix libgcc2 so that eh.o is compiled with -fexceptions. This has been fixed and should be OK in the next snapshot. * Fix the "flow control problem" for exceptions. We know what the problem is and have a pretty good idea how to solve it. We just need to sit down and do it. * Some assemblers choke on current dwarf2 EH output because they do not have a ".ascii" directive. A prototype solution for this problem will also be in the next snapshot. * Final/regression testing. So, what can you do to help? On Linux, both libc and libstdc++ use libio, in such a way that cin/cout/cerr and stdin/stdout/stderr are the same object. If egcs installs a libstdc++ with a newer version of libio than already in libc, problems may occur. This presents a unique set of technical problems that egcs must solve to build, install and work out of the box on Linux systems. We believe that these technical problems have been addressed for the major Linux distributions, including Red Hat, Debian, Slackware, SuSE, Caldera, etc. We also believe these problems have been addressed for the major libc versions currently in use on "roll your own" Linux systems. We would greatly appreciate your help in verifying that egcs works without modification on the most popular Linux systems. If you do build, install & test egcs on a Linux system, please tell us and include the following information: * If you got your Linux distribution from one of the major Linux distributors, tell us which one and what version. * The libc version on your system (find out by "echo /lib/libc.so.*") * The binutils version on your system (find out with "as -v" or "ld -v") * The version of ldd/ld.so on your system (find out with "ldd -v") Note the x86 EH implementation in egcs requires more recent assembler than is found in the binutils-2.7 and binutils-2.8 distributions. The gas snapshot from binutils 2.8.0.1.15 should work. We are also going to need some standardized testing on major platforms. This has two significant components: * Running the gcc/g++ tests with a gcc-2.7.2 based compiler. Note you do not need to re-install them to run the testsuite. If you have them installed you can run the testsuites against those compilers by doing the following: First, you must get out of the egcs object directory. So change directories into your home directory, /tmp or somewhere else. Second, you need an appropriate site.exp. Here is a template: set rootme "." set srcdir "/foo/egcs/gcc" set target_triplet hppa1.1-hp-hpux10.20 set tmpdir /tmp set srcdir "${srcdir}/testsuite" set GCC_UNDER_TEST /foo/bar/com/gcc set GXX_UNDER_TEST /foo/bar/com/g++ Obviously you have to change "srcdir" to the directory where your egcs/gcc sources are located. You should set target_triplet to the canonical name of your system. Running "config.guess" from the toplevel egcs source directory will tell you the canonical name of your system. Set GCC_UNDER_TEST and CXX_UNDER_TEST to the fully qualified pathname to a gcc-2.7.2.* version of gcc & g++. Then run the tests with the following commands: runtest --tool gcc runtest --tool g++ * We also need _standardized_ tests run for egcs on the same system. ie "configure; make bootstrap; cd gcc; make -k check" to run the gcc, g++ & g77 testsuites. Then cd libraries/libio; make check cd libraries/libstdc++; make check Will run the libio and libstdc++ testsuites. When reporting "final test", results, be sure to include the name of your target (ie hppa1.1-hp-hpux10.20), and any configure options you used (other than --prefix), and what assembler/linker you are using (either vendor supplied or the GNU versions). We will need this done for a wide variety of popular platforms including Various Linux configurations (x86, powerpc, sparc, and alpha targets). sparc-sun-sunos sparc-sun-solaris hppa1.1-hp-hpux mips-sgi-irix5 mips-sgi-irix6 powerpc-ibm-aix (or rs6000-ibm-aix) m68k-hp-netbsd alpha-dec-osf x86-freebsd x86-netbsd To avoid duplication of work I'm volunteering to coordinate testing. If you want to be involved with testing, contact me directly. Tell me exactly what configuration you can test (ie the canonical name returned by "config.guess"). If Linux, tell me what distributor it is from (if any) and what version of libc, binutils & ld.so is on the system. Once I get the initial batch of testers I'll send out another message detailing what systems we have testers for and what systms we still need testers for. The following native configurations already have testers: hppa1.1-hp-hpux10.20 m68k-hp-netbsd1.2 m68k-next-nextstep3 sparc-sun-solaris2.6 sparc-sun-solaris2.5 i586-pc-linux-gnulibc2 (RH 4.2 libc5.3.12+RH patches, HJ's gas snapshot from binutils 2.8.0.1.15) We also have someone to test some of the various rtems configurations, including powerpc-rtems and sparc-rtems. And we also have someone to test some cross compilers. Mostly to look for any generic problems -- problems specific to these targets may not be fixed (depends on severity). mn10300-elf (law) mn10200-elf (law) v850-elf (law) h8300-hms (law) If you wish to test some other target, please do so. We can't guarantee that we'll fix the problems though. Our concentration will be on the major native platforms and a few cross platforms. Thank you for your time and contributions! -- Jeff Law (law@cygnus.com) Cygnus Solutions EGCS GNU Compiler System http://www.cygnus.com http://www.cygnus.com/egcs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: egcs@cygnus.com, egcs-announce-outgoing@cygnus.com Cc: zing@cygnus.com Subject: Release Status Date: Thu, 04 Dec 1997 14:03:00 -0000 Message-ID: <5419.878248382@hurl.cygnus.com> X-SW-Source: 1997-1998/msg00000.html Message-ID: <19971204140300.lh6VxWVEO79ka5xoym6BDCXUs7Bxqekp1wEq8k3M4RY@z> As most of you know, we had hoped to get an initial EGCS release made by Sept 1997. It is now close to Nov 1997, so obviously we missed our target date. Without going into all the details, the problem has been part technical and part manpower shortage to deal with the technical issues. The good news is we believe we have cleared the major technical hurdles and the remaining issues should be fairly easily resolved. The delay has also given us the chance to install some significant C++ template improvements, Fortran performance improvements and add an integrated libio/libstdc++ which works with popular Linux systems. So, here is the outstanding issues that need to be resolved before the first release. * Fix the "NULL" problems on Linux. We believe this is the last hurdle to having a compiler & runtime libraries that work out of the box on the most popular Linux configurations. A prototype solution will be in the next snapshot. * Improved EH implementation. There are three issues that still need to be addressed before we are going to consider the EH implementation ready for the first egcs release. * Fix libgcc2 so that eh.o is compiled with -fexceptions. This has been fixed and should be OK in the next snapshot. * Fix the "flow control problem" for exceptions. We know what the problem is and have a pretty good idea how to solve it. We just need to sit down and do it. * Some assemblers choke on current dwarf2 EH output because they do not have a ".ascii" directive. A prototype solution for this problem will also be in the next snapshot. * Final/regression testing. So, what can you do to help? On Linux, both libc and libstdc++ use libio, in such a way that cin/cout/cerr and stdin/stdout/stderr are the same object. If egcs installs a libstdc++ with a newer version of libio than already in libc, problems may occur. This presents a unique set of technical problems that egcs must solve to build, install and work out of the box on Linux systems. We believe that these technical problems have been addressed for the major Linux distributions, including Red Hat, Debian, Slackware, SuSE, Caldera, etc. We also believe these problems have been addressed for the major libc versions currently in use on "roll your own" Linux systems. We would greatly appreciate your help in verifying that egcs works without modification on the most popular Linux systems. If you do build, install & test egcs on a Linux system, please tell us and include the following information: * If you got your Linux distribution from one of the major Linux distributors, tell us which one and what version. * The libc version on your system (find out by "echo /lib/libc.so.*") * The binutils version on your system (find out with "as -v" or "ld -v") * The version of ldd/ld.so on your system (find out with "ldd -v") Note the x86 EH implementation in egcs requires more recent assembler than is found in the binutils-2.7 and binutils-2.8 distributions. The gas snapshot from binutils 2.8.0.1.15 should work. We are also going to need some standardized testing on major platforms. This has two significant components: * Running the gcc/g++ tests with a gcc-2.7.2 based compiler. Note you do not need to re-install them to run the testsuite. If you have them installed you can run the testsuites against those compilers by doing the following: First, you must get out of the egcs object directory. So change directories into your home directory, /tmp or somewhere else. Second, you need an appropriate site.exp. Here is a template: set rootme "." set srcdir "/foo/egcs/gcc" set target_triplet hppa1.1-hp-hpux10.20 set tmpdir /tmp set srcdir "${srcdir}/testsuite" set GCC_UNDER_TEST /foo/bar/com/gcc set GXX_UNDER_TEST /foo/bar/com/g++ Obviously you have to change "srcdir" to the directory where your egcs/gcc sources are located. You should set target_triplet to the canonical name of your system. Running "config.guess" from the toplevel egcs source directory will tell you the canonical name of your system. Set GCC_UNDER_TEST and CXX_UNDER_TEST to the fully qualified pathname to a gcc-2.7.2.* version of gcc & g++. Then run the tests with the following commands: runtest --tool gcc runtest --tool g++ * We also need _standardized_ tests run for egcs on the same system. ie "configure; make bootstrap; cd gcc; make -k check" to run the gcc, g++ & g77 testsuites. Then cd libraries/libio; make check cd libraries/libstdc++; make check Will run the libio and libstdc++ testsuites. When reporting "final test", results, be sure to include the name of your target (ie hppa1.1-hp-hpux10.20), and any configure options you used (other than --prefix), and what assembler/linker you are using (either vendor supplied or the GNU versions). We will need this done for a wide variety of popular platforms including Various Linux configurations (x86, powerpc, sparc, and alpha targets). sparc-sun-sunos sparc-sun-solaris hppa1.1-hp-hpux mips-sgi-irix5 mips-sgi-irix6 powerpc-ibm-aix (or rs6000-ibm-aix) m68k-hp-netbsd alpha-dec-osf x86-freebsd x86-netbsd To avoid duplication of work I'm volunteering to coordinate testing. If you want to be involved with testing, contact me directly. Tell me exactly what configuration you can test (ie the canonical name returned by "config.guess"). If Linux, tell me what distributor it is from (if any) and what version of libc, binutils & ld.so is on the system. Once I get the initial batch of testers I'll send out another message detailing what systems we have testers for and what systms we still need testers for. The following native configurations already have testers: hppa1.1-hp-hpux10.20 m68k-hp-netbsd1.2 m68k-next-nextstep3 sparc-sun-solaris2.6 sparc-sun-solaris2.5 i586-pc-linux-gnulibc2 (RH 4.2 libc5.3.12+RH patches, HJ's gas snapshot from binutils 2.8.0.1.15) We also have someone to test some of the various rtems configurations, including powerpc-rtems and sparc-rtems. And we also have someone to test some cross compilers. Mostly to look for any generic problems -- problems specific to these targets may not be fixed (depends on severity). mn10300-elf (law) mn10200-elf (law) v850-elf (law) h8300-hms (law) If you wish to test some other target, please do so. We can't guarantee that we'll fix the problems though. Our concentration will be on the major native platforms and a few cross platforms. Thank you for your time and contributions! -- Jeff Law (law@cygnus.com) Cygnus Solutions EGCS GNU Compiler System http://www.cygnus.com http://www.cygnus.com/egcs