Martin Michlmayr writes: > * Falk Hueffner <[EMAIL PROTECTED]> [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. http://gcc.gnu.org/ml/gcc/2007-02/msg00390.html 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;[EMAIL > PROTECTED] 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;[EMAIL > PROTECTED] 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. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
