ToolchainRoadmap

Differences between revisions 24 and 25
Revision 24 as of 2005-11-04 01:40:37
Size: 1647
Editor: 209
Comment: updating for dapper
Revision 25 as of 2005-11-04 16:12:21
Size: 3029
Editor: 209
Comment: add ia32-libs stuff/libstdc++/g++-3.4 stuff
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
  * Contributors: MattZimmerman[[BR]]
  * Interested: JimMcQuillan [[BR]]
  * Status: BreezyGoal, DistroSpecification
Line 33: Line 30:
   * Try to avoid using g++-3.4 for main, depends on upstream bugs fixed in g++-4.0.
Line 34: Line 32:

 * libstdc++: Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore.
 * libstdc++: Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore. Needs some work, see below. Should be done, as soon as the effected packages are known.
 * ia32-libs*:
   * Update ia32-libs* to the current library versions (missed for breezy), drop the libraries, which can be built from the source packages and where we already build lib64 packages, and build lib32 packages instead (November 2005).
   * if OOo is built natively for amd64, drop most of ia32-libs. Do not care about ia32-libs for ia64. If necessary, provide a cross toolchain for ia64 (ia64->i386) to build the required libraries (done for binutils and gcc, needs work for glibc), very low priority.
Line 39: Line 39:
 * Decide on glibc update (JeffBailey)  * Decide on a glibc update (when, to which version) (JeffBailey)
 * libstdc++6 is configured to use the mt allocator based on discussions with upstream libstdc++ developers. This configuration turned out to be a mistake (memory leaks and still buggy), other distributions did change back to the new allocator (the default one) this summer. The change does not effect symbols exported from libstdc++, but libraries, which use containers from the template headers, using a allocator. What needs to be done:
   * Configure libstdc++ to use the new allocator.
   * Identify all library packages depending on libstdc++ and exporting *mt_alloc* symbols.
   * rebuild these libraries and depending packages. Note that partial upgrades won't work with this procedure. To make this work we would have to change the package name for all libraries effected.

Toolchain Roadmap

Status

Summary

Upgrade the toolchain to new minor/subminor versions. Maybe upgrade gij/gcj to a recent version (4.1), if needed for Edubuntu. Change libstdc++ configuration to use the new

Rationale

We do not want to introduce new upstream versions in the dapper time frame, just fixing bugs in the existing toolchain packages.

Implementation Plan

  • glibc:
    • merge to the Debian 2.3.5 packages, if 2.3.6 is released in 2005, consider an upgrade
  • binutils:
    • fix architecture specific bugs, if 2.17 is released in 2005, consider an upgrade.
  • gcc:
    • Move gcc-3.3 sources to universe, just build the libstdc++5 runtime library package from these sources
    • keep gcc-3.4 (upstream glibc-2.3.x cannot be built with 4.0 without patches, upstream asks for a g77 compiler as long as gfortran isn't mature enough, pascal is built by gcc-3.4 only, but universe anyway). Update to gcc-3.4.5 when released
    • Try to avoid using g++-3.4 for main, depends on upstream bugs fixed in g++-4.0.
    • Update gcc-4.0 to gcc-4.0.3 when released
  • libstdc++: Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore. Needs some work, see below. Should be done, as soon as the effected packages are known.
  • ia32-libs*:
    • Update ia32-libs* to the current library versions (missed for breezy), drop the libraries, which can be built from the source packages and where we already build lib64 packages, and build lib32 packages instead (November 2005).
    • if OOo is built natively for amd64, drop most of ia32-libs. Do not care about ia32-libs for ia64. If necessary, provide a cross toolchain for ia64 (ia64->i386) to build the required libraries (done for binutils and gcc, needs work for glibc), very low priority.

Outstanding Issues

  • Decide on a glibc update (when, to which version) (JeffBailey)

  • libstdc++6 is configured to use the mt allocator based on discussions with upstream libstdc++ developers. This configuration turned out to be a mistake (memory leaks and still buggy), other distributions did change back to the new allocator (the default one) this summer. The change does not effect symbols exported from libstdc++, but libraries, which use containers from the template headers, using a allocator. What needs to be done:
    • Configure libstdc++ to use the new allocator.
    • Identify all library packages depending on libstdc++ and exporting *mt_alloc* symbols.
    • rebuild these libraries and depending packages. Note that partial upgrades won't work with this procedure. To make this work we would have to change the package name for all libraries effected.

ToolchainRoadmap (last edited 2008-08-06 16:34:44 by localhost)