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