GCC 4.1 in experimental / GCC for etch
The GCC (GNU compiler collection) 4.1 release candidate 1 can be found
in experimental. "Porters", please make sure that the package is
built and uploaded (if it's not built by the experimental
buildd). Please check that the symbols exported in the 4.1 libraries
are a superset of those exported in the 4.0 libraries (these are
libgcc1 (except m68k and hppa), libstdc++6, libffi4, libobjc1,
libmudflap0).
The proposed GCC plan for etch consists of:
- uploading GCC 4.0.3 to unstable (this release is expected shortly
after the GCC 4.1.0 release), let 4.0.3 migrate to testing.
- uploading GCC 4.1 to unstable for those architectures which do not
have ABI problems (these should be all, but should be validated).
- Once the 4.1 packages are migrated to testing, make 4.1 the default
compiler for i386, amd64, powerpc. These are the architectures,
which are considred primary (linux) architectures by GCC upstream.
For the other Debian architectures, the GCC port maintainers and the
Debian port maintainers should make the call, if and when the
default GCC is changed.
- Make gij-4.1/gcj-4.1 the default for all architectures.
- Stop building compiler packages from the GCC 3.3 source; the only
packages built will be libstdc++5 (and libgcc1 on hppa/m68k).
- Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4
and g++-3.4 (it looks like we can go without g++-3.4 for the etch
release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be
found anymore in 4.x releases.
- Stop building all compilers from 4.0, which are not the default for
some port (except gcc-4.0).
- GCC 2.95 was requested to be shipped with etch. Currently alpha
FTBFS and needs to be disabled.
In an ideal world, we'll ship with not more than three different
compiler versions (4.1, 3.4, 2.95), plus runtime libs from another
compiler version (3.3).
Still open points are
- GNAT maintainance. Supposed to be based on 4.1. The GNAT maintainer
isn't a DD yet (after more than a year of GNAT maintainance in
Debian I'm loosing trust in our NM process).
- Fortran roadmap. There are some problems mixing g77 / gfortran code.
AFAIK nobody cares too much about the Fortran compilers to define
a strategy/upgrade policy.
That's a proposal, not a decision. I'll summarize feedback and
propose a more final plan when there's some kind of agreement.
Matthias
Reply to: