I got sick of listening to people discuss the gcc 3.2 transition in an uninformed manner. So I've whipped up a transition plan which will hopefully get us from A to B without causing too much pain. Haha. I'm entirely fallible and I don't pretend to understand all the issues involved with doing the transition. But by writing down a plan at least it can be updated and fixed before we have to start _doing_ the transition.
Comments and corrections welcomed. The most up to date version of this document is at http://people.debian.org/~willy/c++transition.html The following is the output from lynx -dump. --------- The Debian GCC 3.2 Transition Plan This is a proposal. You will be notified when this is a real plan Note! m68k and arm have not yet uploaded gcc-3.2. Until they do, we cannot start this transition! Note! We need to check glibc and binutils work properly with gcc-3.2 on all architectures! Until this is done, we cannot start this transition! 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 g++ 2.95 for ever. This is a proposal. You will be notified when this is a real plan So what're we going to do? * If your package contains no C++, do nothing. One fine day, gcc-defaults will be changed to gcc-3.2 and you'll start using GCC 3.2 with no work by yourself. * If you maintain a library written in C++, add a `c' to the end of the name of your .deb, eg libdb4.0++.deb -> libdb4.0++c.deb. This is similar in spirit to the glibc transition adding `g' to the end of libraries. * You should not add a `c' to your -dev package. * The exact placement of the `c' 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 `c' adjacent to the soname number, eg libqt3c-mt-odbc, but if your package ends in a ++, put the `c' after that. * Add a Conflict with the non-`c' version of the package. * Ensure that you're using g++-3.2 to build your library (setting CXX in the environment will normally do the trick). * Add a build-dependency on g++-3.2 in your control file (this can be removed after gcc-defaults is changed). * Wait until all your dependencies have been uploaded in `c' versions. * Upload and rejoice! At some point in the future, we will change gcc-defaults to make gcc-3.2 the default on all architectures. At that time, you should remove the setting of CXX and the explicit dependency on g++-3.2. You should not rename your package to remove the `c' suffix until upstream change their soname. This is a proposal. You will be notified when this is a real plan 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 `c' 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. What about other architectures? The rules I've outlined above should make the autobuilders build your packages with GCC 3.2. Help! My package doesn't build with GCC 3.2 Typically this is because your package isn't actually written in C++ but some "extended subset" of it. You may want to talk to upstream about getting it converted. 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 really can't get your package fixed, you should change to build-depend on g++-2.95. 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. This is a proposal. You will be notified when this is a real plan -- Revolutions do not require corporate support.
