public inbox for gcc-announce@gcc.gnu.org
 help / color / mirror / Atom feed
* Release Status
@ 1997-10-30 13:51 Jeffrey A Law
  1997-12-04 14:03 ` Jeffrey A Law
  0 siblings, 1 reply; 2+ messages in thread
From: Jeffrey A Law @ 1997-10-30 13:51 UTC (permalink / raw)
  To: egcs, egcs-announce-outgoing; +Cc: zing

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


^ permalink raw reply	[flat|nested] 2+ messages in thread
end of thread, other threads:[~1997-12-04 14:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-10-30 13:51 Release Status Jeffrey A Law
1997-12-04 14:03 ` Jeffrey A Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).