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 <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]