* 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
* Release Status
1997-10-30 13:51 Release Status Jeffrey A Law
@ 1997-12-04 14:03 ` Jeffrey A Law
0 siblings, 0 replies; 2+ messages in thread
From: Jeffrey A Law @ 1997-12-04 14:03 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).