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

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: