[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

gcc 3.2 transition in unstable



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: pgppOeLOhIjtU.pgp
Description: PGP signature


Reply to: