-----BEGIN PGP SIGNED MESSAGE-----

With today's dinstall run, new gcc/g++ packages are entering the
archives and GCC 4.0 is the default gcc/g++. Starting from now, please
DON'T upload any C++ code, which build-depends on a library written in
C++ that is not yet converted to the new C++ ABI.  Details for the C++
ABI change are at the end of the message. How do we go on?

- - The buildd admins make sure, that build-essential (>= 11), gcc (>=
  4:4.0) and g++ (>= 4:4.0) are installed on the buildds.

- - Package maintainers must update all their build environments to
  gcc (>= 4:4.0) and g++ (>= 4:4.0).

Each of the three following points can be done in parallel:

- - Rebuild C++ applications, which do not depend on any other C++
  library besides libstdc++.

- - Rename and rebuild C++ libraries, which do not depend on any
  other C++ library besides libstdc++. See below for the details.

- - All other applications and libraries have to wait, until the C++
  related build dependencies are available for the new ABI. It's
  important to adjust the build dependencies and the dependencies of
  the -dev packages to the first version of a package, which is built
  for the new ABI. See below for the details.

For the time until all C++ libraries are converted, we use the 
following NMU policy for uploads related to the C++ ABI change:

- - 0-day NMU's allowed for all C++ library packages, which are uploaded
  after the g++ default change, and are completely ignoring the C++
  ABI change.

- - 2-day NMU's allowed for all C++ library packages, which are uploaded
  after the g++ default change, with serious bugs in the packaging
  (i.e. wrong package name in shlibs file, missing conflicts/replaces,
  library package without a library, etc).

- - 5-day NMU for all C++ library packages, which can be converted, but
  are left alone.

i.e. if libfoo1++ depends on libbar1++, libfoo1++ can be NMU'ed 5 days
after libbar1++ is uploaded.


Besides the C++ ABI change, all m68k and hppa packages depending on
libgcc1 have to be rebuilt to use libgcc2.


Have fun

        Matthias


PS: Some of you know, that Ubuntu did the C++ ABI change at the start
    of it's release cycle.  For most if the libraries, patches are
    available. These have to be adjusted, at least for the version
    numbers. These patches may be outdated, some think they are too simple,
    and it doesn't make sense to submit those to the Debian BTS. All
    others may have a look at http://wiki.ubuntu.com/CxxLibraryList


- ----------------------------------------------------------------------

C++ ABI Transition
==================

Debian already had a C++ transition in 2002. Still remember? We are
proposing the same schema for the forthcoming ABI transition. The
following text is derived from this plan.

- - 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/4.0 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 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.

- - How is it called?

  The C++ ABI has many names (no, actually only two). G++ 3.2/3.3 have
  the Version 1, 3.4/4.0 have the version 2. To get the ABI version:

    g++ -E -dM - < /dev/null | awk '/GXX_ABI/ {print $3}'

  Compilers with ABI version 1 print '102', those with version 2 print
  1002. During the last C++ ABI transition package names were renamed
  from libfoo to libfooc102. So rename them to libfooc1002 this time?

  No,
  - if your package is called libfoo1, add the string ''c2'' to the
    package name (see below).
  - if your package is called libfoo1c102, then replace c102 with c2
    or drop the ''c102'' from the package name (see below).

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

  * Please don't add build dependencies on g++ (>= 4.0) or
    build-essential (>= 11).

  * There will be a Lex KDE (i.e. don't rename library packages depending
    on kdelibs4 / kdelibs4c2, the KDE maintainer should followup on this.

  * Add a build dependency on c++abi2-dev for all source packages, which
    build using g++, but which binaries do not depend on libstdc++.
    I.e. packages like festival.

  * 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 (check the
      update_excuses file).

    * If your package does not contain the c102 suffix, 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.

    * There is usually more to do than just editing the control file.
      I.e. change the shlibs file, renaming debian/* files, updating
      build dependencies etc.  For some package changes, you can find
      some hints at http://wiki.ubuntu.com/CxxLibraryList.

    * Packages with c102 suffix. CHANGED FROM PREVIOUS PROPOSALS,
      READ AGAIN:

      There has been a concern about re-renaming library packages
      libfoo1c102 back to libfoo1, because this might break third
      party packages on systems, that are directly upgraded from
      potato to etch.  I don't know any of these, but if a package
      maintainer thinks it's worth supporting these packages and
      upgrades, please rename the package to libfoo1c2. In this case
      you have to keep the libfooc1 conflict/replace and add the
      libfoo1c102 conflict/replace. There are two ways:

      - Preferred: Replace the c102 suffix with a c2 suffix, add
        Conflict/Replaces to the c102 package. Don't remove any
        Conflicts/Replaces, i.e.:

          Package: libfoo1c102
          Conflicts: libfoo1
          Replaces: libfoo1

        becomes:

          Package: libfoo1c2
          Conflicts: libfoo1, libfoo1c102
          Replaces: libfoo1, libfoo1c102

      - Alternative: Drop the suffix from the package name. (that
        works, because we don't support direct upgrades from woody to
        etch). Add a Conflict with the non-c2 version of the package
        (the previous version), i.e.

          Package: libfoo1c102
          Conflicts: libfoo1
          Replaces: libfoo1

        becomes:

          Package: libfoo1
          Conflicts: libfoo1c102
          Replaces: libfoo1c102

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

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

  * 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 ;-)
      You should see a dependency on libstdc++6, if you see one on
      libstdc++5, something is wrong.

    * 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 c2 suffix
  until upstream changes their soname.

- ----------------------------------------------------------------------

Some more FAQ's
===============

- - 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
  LSB3 intends to standardise the GCC 4.0 ABI; for Ubuntu/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
  c2 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 (.5 to .6) transition, we
  could do this because they used different dynamic linkers. For this
  transition, there is also little to gain in having full backwards
  compatibility to the old ABI. The only gain is that third party
  binary only applications that dynamically link to C++ using-libs
  (other than the stdc++ library itself) continue to work.  What about
  other architectures?

- - The rules outlined above should make the autobuilders build your
  packages with GCC 4.0.

  For other architectures there are other incompatibilities:

  * i.e. sparc and hppa. I.e.: hppa libgcc1 (SJLJ) -> libgcc2
    (Dwarf2) transition. I.e.: sparc ABI change from 3.3 to 3.4.

  * The SPARC ABI changes should only relate to complex numbers or
    less used parts of the SPARC64 ABI.  Mathmatical packages probably
    should be NMU'd once glibc has been compiled with GCC 4.0 for
    SPARC.

  Generally, don't use GCC 3.3 anymore for new uploads.

- - Help! My package doesn't build with GCC 4.0

  First search for the error in your package, not in GCC. g++-4.0 is
  more strict to the C++ standard than g++-3.3, and as such, things
  not written in standard C++, but written in an "extended subset" of
  it, using gnu extension classes that are no longer supported. See
  http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus and
  http://gcc.gnu.org/gcc-4.0/changes.html

  If you find an internal compiler error (ICE), then submit a bug
  report. Please look at the error message that gcc emits: in most
  cases gcc asks for the preprocessed source file to be submitted
  together with the command line that was used to produce the
  file. Recompile the file using "-save-temps" and include the
  (compressed) .i or .ii file in the report.

  If you want help with debugging, download the gcc-snapshot package
  and retry compiling your package with this gcc. Please see the
  README in the package how this works. In no case should a package
  built by gcc-snapshot be uploaded to the archive.

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

- - How do I know when all of my dependencies have been uploaded on all
  architectures?

  The madison command on merkel (accessible for Debian developers),
  followed by the package name of your 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.

- - Why not use GCC 3.4 as the default compiler?

  Upstream did announce one more GCC 3.4.x release; with the
  availability of a newer released compiler version, the older
  branches usually get less attention. Because 3.4 and 4.0 are
  supposed to be ABI compatible, we can use GCC 3.4 as a fallback.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.5.8, an Emacs/PGP interface

iQEVAwUBQsq7mguDzMCIcnEhAQE81Af/adAfJ+9Bb3nsEcP0YhBIuawyFcSY77/R
BqE9uTYvvQDKmMOHz9M54MdLHGyvcBySJk7p1+2AE6NljZehQQOIILUUMGkfyjmX
alXjnAqNqR0Rt9trXEauZLt7OsopjW9AfCXzFv5zwfGyoQnrlxxMvzfSJdJio9nY
IWmAfdHoWNjrH7L1QqtGVv1p5LL4BFbtNeKCT7p51ff4BnQeNGe03ydVsb5IKyH2
1C+X4GS+OIs0pEInMxKO7NzxMselPuhjMEIVJzkO6RG67Yc2Kfun7ZwKr8+anwLy
6mXW1Wiy32+oFAXU6sGbxaPKoJvVK2EIEur7V0Elru39fyHaLgSTjA==
=VP77
-----END PGP SIGNATURE-----


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to