[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc plans for the lenny cycle

Martin Michlmayr writes:
> * Falk Hueffner <falk@debian.org> [2007-04-13 19:42]:
> > gcc 4.2.0 will be released Real Soon Now (next few months). Changes
> > are not very disruptive, I suppose not very many packages will fail
> > to build. It will probably stabilize within a few months.

we will start lenny with a mix of GCC versions:

 - GCC 4.1 updated to the 4.1.2 release, triggering the ldbl64 to
   ldbl128 transition on some architectures.
   The gcc-4.1 upload will happen after an updated binutils is
   available in unstable.

 - Gfortran updated to the current 4.2 prerelease, triggering the g77
   to gfortran transition.

 - gij/gcj updated from the Fedora gcc-4_1-branch (which is a backport
   from the trunk introducing Java 1.5 compatibility).

Next GCC 4.2 will be prepared to be included in unstable; a current
issue is http://sourceware.org/bugzilla/show_bug.cgi?id=4302 which has
to be resolved before g++-4.2 can enter unstable.

GCC 4.2 as the default compiler might be possible, there are a few
thing to be aware of: 

 - A performance regression on some code.
   These regressions are somewhat compensated by other optimizations
   (namely the -mtune=generic changes on i386 and amd64) when
   comparing unpatched 4.1 and 4.2 compilers, but will be visible with
   our 4.1 compiler having the -mtune=generic backport for lenny.

 - Other distributions will likely stick to GCC 4.1, avoiding GCC 4.2
   and going directly to 4.3. 4.2 might get less test coverage than
   4.1 or 4.3.
> > gcc 4.3.0 release is harder to estimate. Maybe mid-2008.  No really
> > earth-shaking internal changes are planned, so it probably will also
> > only take a few months to stabilize. A number of C++ packages will
> > fail to build because the header dependencies have been streamlined;
> > however, they should be very easy to fix.

Looking at the timeframe, this looks like the time when 4.1 did enter
sid; it's too early to have a decision about 4.3 as the default
compiler now, but we should have it as an option.

For lenny we should drop 3.3, 3.4 and 4.0 (hppa only) from the release
(if nobody complains, 2.7.2 and 2.95 as well).

Martin Michlmayr writes:
> FWIW, I've been keeping track of 4.2 related package bugs:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.2;users=tbm@cyrius.com

Martin Michlmayr writes:
> "a few" =~ 400, but yes, they are trivial to fix and patches for
> almost all of them exist.  I'll start filing other 4.3 related bugs in
> the coming weeks.
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.3;users=tbm@cyrius.com

I would like to see these as beeing considered RC (or at least
important), so that these get fixed now with regular updates, and do
not need to be fixed in a concentrated effort just before the
introduction of a new compiler.

ldbl64 -> ldbl128 transition:

on powerpc, s390, sparc and alpha (plus unofficial ppc64) the "long
double" data type did change from 64bit to 128bit.  glibc and
libstdc++6 itself come with a compatibility layer to support both
representations.  All other libraries exposing this data type in
public interfaces need to be renamed (adding a ldbl suffix) and
rebuilt, then all other packages depending on these renamed libraries
need a rebuild.  These are about 120 libraries (currently determined
scanning header files in /usr/include).  If we do not care about
partial upgradeability on these platforms, this transition could be
handled by NMUs as well.  If somebody wants to help with this
transition please contact me.

g77 -> gfortran transition:

gfortran 4.2 is considered by upstream to become a replacement for
g77;  for partial upgradeability it is necessary that code isn't
linked with -lg2c and -lgfortran at the same time.  The best thing to
enforce this is to rename each library package having a library built
with g77 when it's built with gfortran (about 40 libraries/packages).
If somebody wants to help with this transition, please contact me.


Reply to: