The C++ transition plan for gcc 3.2 is ready to be implemented. The latest
version of the plan (as it now is, rather than a proposal) can be viewed at:
http://people.debian.org/~rmurray/c++transition.html
gcc-defaults will be uploaded after dinstall time tomorrow.
I've included the output of lynx -dump below:
The Debian GCC 3.2 Transition Plan Version 2
Why do we need one?
Because GCC 3.2 changed the C++ ABI. You can't mix a C++ library
compiled with GCC 3.2 and a C++ application compiled with an earlier
version, or vice versa.
Transitions are painful. This will be no exception. The rules here are
designed to make it as smooth as possible, but it's still going to be
unpleasant. We have to do it, we can't stay with GCC 2.95 for ever.
Other distributions are switching to 3.2, and most of our ports will
have much better toolchains with the newer compiler.
So what're we going to do?
We're going to rebuild all C++ packages with the gcc-3.2 ABI, except
for libqt2, which will be staying with the ABI it currently has for
compatibility with woody and third party binaries built with libqt2.
libqt3 will use the new ABI.
* If you have workarounds to build with a specific gcc version on
certain architectures, these should be removed (gcc-3.0 will not
be staying in the archive for long). Also if there are specific
optimization settings that have been used to workaround compiler
bugs, these should be removed, if possible.
* If you maintain a library written in C++:
+ Wait until all of your dependencies have been uploaded in
`c102' versions, and rebuilt on all architectures.
+ If you are building for libqt3 or don't depend on libqt in
any way:
o add a `c102' to the end of the name of your .deb, eg
libdb4.0++.deb -> libdb4.0++c102.deb. This is similar in
spirit to the glibc transition adding `g' to the end of
libraries.
o You should not add a `c102' to your -dev package.
o The exact placement of the `c102' can be tricky. It's
not terribly important; the important thing is that the
new package conflicts with the old and has a different
name. Stylistically, we prefer to keep the `c102'
adjacent to the soname number, e.g. libqt3c102-mt-odbc,
but if your package ends in a ++, put the `c102' after
that.
o Add a Conflict with the non-`c102' version of the
package.
o Ensure that you're using g++-3.2 to build. You should
have g++ (>= 2:3.2) installed on the system you build
on.
o Optionally, you may wish to add a note in your package
description that this version of your library is for use
with GCC 3.2.
+ If it depends, either directly or indirectly, on libqt2:
o Build using libqt3, if possible, and see the previous
section.
o Otherwise, change the package to build-depend on
gcc-2.95 [!hppa !ia64], g++-2.95 [!hppa !ia64], gcc-2.96
[ia64], g++-2.96 [ia64], gcc-3.0 [hppa], g++-3.0 [hppa]
o Change the package to use gcc-2.95 and g++-2.95 in the
build process for most archs, -3.0 on hppa, and -2.96 on
ia64
o These packages will be staying with the old ABI that we
have already shipped with. Many of these packages are
part of KDE, and will be replaced with KDE3/QT3 versions
anyways.
* If you maintain a library or a program written in C++, that isn't
part of the qt2 dependency chain:
+ Wait until all your dependencies have been uploaded in `c102'
versions, and rebuilt on all architectures.
+ If your Depends: line isn't generated automatically, you'll
need to change it too. But you should be using dpkg-shlibdeps
anyway ;-)
+ Upload and rejoice!
* If your package contains no C++, do nothing more. You'll start
building with the new gcc on your next upload.
You should not rename your package to remove the `c102' suffix until
upstream changes their soname.
Why don't we just change the sonames?
Because upstream chooses the soname to match their API. If we change
the soname then we render ourselves binary-incompatible with other
distros and vendor-supplied binaries. This is important because the
LSB intend to standardise the GCC 3.2 ABI; for Debian to become
binary-incompatible at this point would be the height of perversity.
Of course, when your upstream does bump the soname, you can drop the
`c102' from the package name, just like very few libs still have a `g'
on the end.
How about versioned symbols?
Versioned symbols don't even pretend to solve ABI transition problems.
Not to mention there's the other-distro compatibility issue --
binaries compiled on Debian would not run on other distros.
Why don't we put the libs in a different directory?
Basically, it's too complex. For the glibc transition, we could do
this because they used different dynamic linkers. For this transition,
there is also little to gain in having full backwards compatibility to
the old ABI. The only gain is that third party binary only
applications that dynamically link to C++ using-libs (other than the
stdc++ library itself) continue to work. The only common case that
comes to mind for this is libqt2 and kdelibs3. Both of these packages
are old, so to keep binary compatibility with previous versions of our
distribution (and some other distributions) is easy. We continue to
build libqt2 and all dependant packages with g++-2.95. Anything using
libqt3, will build with the new ABI, along with other C++ libraries.
What about other architectures?
The rules outlined above should make the autobuilders build your
packages with GCC 3.2.
Help! My package doesn't build with GCC 3.2
First search for the error in your package, not in gcc. g++-3.2 is
more strict to the C++ standard than g++-2.95, and as such, things not
written in standard C++, but written in the g++-2.95 "extended subset"
of it, using gnu extension classes that are no longer supported.
Fortunately, due to hppa using GCC 3.0 for woody, you've probably had
a bug filed against your package for at least six months, so this is
no surprise to you.
If you find an internal compiler error (ICE), then submit a bug
report. Please look at the error message that gcc emits: in most cases
gcc asks for the preprocessed source file to be submitted together
with the command line that was used to produce the file. Recompile the
file using "-save-temps" and include the (compressed) .i or .ii file
in the report.
If you want help with debugging, download the gcc-snapshot package and
retry compiling your package with this gcc. Please see the README in
the package how this works. In no case should a package built by
gcc-snapshot be uploaded to the archive.
If you really can't get your package fixed, you should change to
build-depend on g++-2.95, and use it in the build process. If you
depend on a library other than libstdc++ (or libg++), you're not
likely to release with sarge. We recommend you statically link to any
C++ libraries (other than libg++) which you use.
Why 'c102' rather than the 'c' previously proposed?
The "102" indicates the version of the C++ ABI. As it is likely that a
future C++ ABI change will be needed, the explicit version will make
it clear which ABI a package is built with.
How do I know what ABI a given g++ is using?
The following command will show you the C++ ABI version being used by
g++:
g++ -E -dM - < /dev/null | awk '/GXX_ABI/ {print $3}'
How do I know when all of my dependencies have been uploaded on all
architectures?
The madison command on auric, followed by the package name of your
dependencies will show you the latest version, and which archs that
version is built for. You should run linda or lintian over your
package, as they have a check for multiple C++ libraries being linked
to a single binary. If you get an error about more than one libstdc++
being linked, not all of your dependencies are updated yet.
What about a timeframe?
Here's what's happening:
* gcc-defaults with 3.2 as default built on all architectures [done]
* gcc-defaults uploaded and installed into buildd chroots [Jan 6]
* announcement that 3.2 is now the default in the archive [Jan 7]
* library packages that have no other c++ dependencies uploaded
* library packages start uploading as dependencies are uploaded
* application packages start uploading as dependencies are uploaded
* various NMUs to help the process along
--
Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org)
The opinions expressed here are my own.
Attachment:
pgpybVkD5625w.pgp
Description: PGP signature