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
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.
Reply to: