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

GCC 3.2 transition

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

   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'
     * 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.

Reply to: