GCC version change / C++ ABI change
This week, we will change the GCC default versions from 3.3 to 4.0
(for g77 and gpc to 3.4, these are not supported in 4.0) on all
architectures. The GCC-4.0 version used is taken from the GCC 4.0
branch (something that will likely become the 4.0.1 release candidate
3). The switch to 4.0 (instead to 3.4) is preferred by the Debian GCC
maintainers and the port maintainers (modulo those I forgot to ask,
please speak up now). Looking forward at the etch release schedule, it
is unlikely that 3.4 is still supported upstream in 18 months. 4.0 is
currently used on by other distributions as a system compiler to build
most of the distribution. We will keep at least the GCC-3.4 C and
Fortran77 compilers for the etch release.
The C++ ABI change was already announced at
http://lists.debian.org/debian-release/2005/04/msg00153.html
There has been a concern about re-renaming library packages
libfoo1c102 back to libfoo1, because this might break third party
packages on systems, that are directly upgraded from potato to etch.
I don't know any of these, but if a package maintainer thinks it's
worth supporting these packages and upgrades, please rename the
package to libfoo1c2. In this case you have to keep the libfooc1
conflict/replace and add the libfoo1c102 conflict/replace.
The timeframe for the change is as follows:
- wait for gcc-4.0 4.0.0-11 in the archives on all architectures,
for sparc and hppa we require the -12 version (Looking at the
buildds, that probably will be 2005-07-0[56]).
- wait for gcc-3.4 3.4.4-3 in the archives on all architectures,
although 3.4.4-4 would be preferred (same estimates as for
gcc-4.0).
- an upgrade to binutils-2.16.1 is a nice to have, currently needs
some more work on mips/mipsel.
- upgrade gcc-defaults to point to the 4.0 compiler drivers.
- upgrade build-essential to version 11 to depend on the new
defaults.
PLEASE do NOT start uploading packages before a new gcc-defaults and
build-essential are in the archives.
After these are in the archives: The following can happen in parallel:
- Rebuild C++ applications, which do not depend on any other C++
library besides libstdc++.
- Rename and rebuild C++ libraries, which do not depend on any
other C++ library besides libstdc++.
All other applications and libraries have to wait, until the C++
related build dependencies are available for the new ABI. It's
important to adjust the build dependencies and the dependencies of the
-dev packages to the first version of a package, which is built for
the new ABI.
Please don't add build dependencies on g++ (>= 4.0) or build-essential
(>= 11). The buildd maintainers will take care, that the buildd's run
with build-essential-11 after it's in the archives.
I'm updating the above mentioned text for the C++ ABI until Wednesday
or Thursday. Feedback and additions are welcome.
For the time until all C++ libraries are converted, I'm proposing the
following NMU policy:
- 0-day NMU's allowed for all C++ library packages, which are uploaded
after the g++ default change, and are completely ignoring the C++
ABI change.
- 2-day NMU's allowed for all C++ library packages, which are uploaded
after the g++ default change, with serious bugs in the packaging
(i.e. wrong package name in shlibs file, missing conflicts/replaces,
library package without a library, etc).
- 5-day NMU for all C++ library packages, which can be converted, but
are left alone.
Matthias
PS: Some of you know, that Ubuntu did the C++ ABI change at the start
of it's release cycle. For most if the libraries, patches are
available. These have to be adjusted, at least for the version
numbers. Some Debian developers think these patches are too simple,
and it doesn't make sense to submit those to the Debian BTS. All
others may have a look at http://wiki.ubuntu.com/CxxLibraryList
Reply to: