From: Jeffrey A Law <law@cygnus.com>
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 [thread overview]
Message-ID: <5419.878248382@hurl.cygnus.com> (raw)
Message-ID: <19971204140300.lh6VxWVEO79ka5xoym6BDCXUs7Bxqekp1wEq8k3M4RY@z> (raw)
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
next reply other threads:[~1997-12-04 14:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-10-30 13:51 Jeffrey A Law [this message]
1997-12-04 14:03 ` Jeffrey A Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5419.878248382@hurl.cygnus.com \
--to=law@cygnus.com \
--cc=egcs-announce-outgoing@cygnus.com \
--cc=egcs@cygnus.com \
--cc=zing@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).