Re: C++ ABI transition for etch
I may make sense to also give a timeframe for the transition like
begin -> libraries get uploaded -> libraries get NMUed -> packages get
uploaded -> packages get removed/NMUed. 2-3 weeks for each step? With
some good placed BSPs we could perhaps make this actually happen...
(but of course depends on the autobuilders, too)
Some corrections:
On Wed, Apr 13, 2005 at 10:24:03PM +0200, Matthias Klose wrote:
> - Why do we need one?
>
> Because GCC 3.4/4.0 changed the C++ ABI. You can't mix a C++ library
> compiled with GCC 3./4.0 and a C++ application compiled with an
4---^
> 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 3.3 for
> ever.
>
> Other distributions did already switch to 3.4 or 4.0, 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.4/4.0 ABI.
>
> * If you have workarounds to build with a specific gcc version on
> certain architectures, these should be removed. 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 c2
> versions, and rebuilt on all architectures.
>
> Add a c2 to the end of the name of your .deb, eg libdb4.0++.deb
> -> libdb4.0++c2.deb. This is similar in spirit to the glibc
> transition adding g to the end of libraries.
>
> * You should not add a c2 to your -dev package.
>
> * The exact placement of the c2 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 c2 adjacent to the soname number,
> e.g. libqt3c2-mt-odbc, but if your package ends in a ++, put the
> c2 after that.
>
> * Add a Conflict with the non-c2 version of the package.
>
> * Ensure that you're using g++-4.0 to build. You should have g++
> (>= 4:4.0) installed on the system you build on (or
> build-essential (>= 11) ). Proposal to bump the build-essential
TODO ---^ (?)
> version for the ABI transition.
>
> Optionally, you may wish to add a note in your package
> description that this version of your library is for use with
> GCC 4.0.
Is this really necessary? I would see that as ugly and for whom this
will be usefull?
> * If you maintain a library or a program written in C++
>
> * Wait until all your dependencies have been uploaded in c2
> 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 ;-)
Perhaps mention here how to see in the shlibdeps if it has worked?
At least they should see libstdc++6 there, shouldn't they?
> * 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 or c2 suffix
> until upstream changes their soname.
>
[...]
> If you really can't get your package fixed, you should change to
> build-depend on g++-3.4, and use it in the build process. If even
> g++-3.4 can't build your package, and your package depend on a
s ---^
> library other than libstdc++, you're not likely to release with
> breezy/etch. We recommend you statically link to any C++ libraries
> which you use.
>
> TODO: Check for each architecture, if that's possible due to arch
> specific changes.
>
> - 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
merkel --^ (the people that can use newraff probably
wouldn't ask the question ;))
> 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.
>
> TODO: update linda/lintian to discover packages linked against two
> different versions of a library (libgcc1/libgcc2,
> libstdc++5/libstdc++6)
Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/
Reply to: