ToolchainRoadmap

Differences between revisions 22 and 38 (spanning 16 versions)
Revision 22 as of 2005-04-29 03:03:36
Size: 4230
Editor: intern146
Comment: approve
Revision 38 as of 2008-08-06 16:34:44
Size: 3337
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
= Toolchain Roadmap =
Line 8: Line 6:
  * Created: [[Date(2005-04-24T00:11:33Z)]] by MattZimmerman[[BR]]
  * Priority: HighPriority[[BR]]
  * People: MatthiasKloseLead, JeffBaileySecond[[BR]]
  * Contributors: MattZimmerman[[BR]]
  * Interested: JimMcQuillan [[BR]]
  * Status: BreezyGoal, DistroSpecification, ApprovedSpecification
  * Packages: [[BR]]
  * Depends: [[BR]]
  * UduSessions: 1(0) [[BR]]
  * Created: 2005-11-02 by MatthiasKlose<<BR>>
  * People: MatthiasKlose, JeffBailey<<BR>>
  * Packages: glibc, binutils, gcc, ia32-libs<<BR>>
  * Launchpad: https://launchpad.net/distros/ubuntu/+spec/toolchain-roadmap
Line 18: Line 11:
== Introduction == == Summary ==
Line 20: Line 13:
Review toolchain status and strategy for Breezy Upgrade the toolchain to new minor/subminor versions. Consider an upgrade for gij/gcj to a recent version (4.1), if needed for Edubuntu. Change libstdc++ configuration to use the new allocator.
Line 24: Line 17:
 * Much improved Java support
 * Better error reporting from C and C++ front-end
 * LSB 3.0 support
 * Fortran 90 support
 * Better optimizations from C compiler
 * Faster compilation at -O0
 * Better standards compliance

== Scope and Use Cases ==

 * gcc-4.0
 * g++-4.0 and associated ABI transition
 * glibc 2.3.5
We do not want to introduce new major upstream versions and unknown bugs in the dapper time frame, just fix bugs in the existing toolchain packages.
Line 40: Line 21:
 * Details at http://www.ubuntulinux.org/wiki/BreezyToolchainTransition === glibc ===
Line 42: Line 23:
Already done: (December 2005)
Line 44: Line 25:
 * Change "gcc" default to 4.0
 * Change "g77" default to 3.4
 * change "cpp" default to 4.0
 * Upload glibc-2.3.5
 * Change powerpc, ia64 to nptl-only
 1. Merge to the Debian 2.3.5 packages.
Line 50: Line 27:
May TODO: If upstream glibc 2.3.6 is released in 2005, consider an upgrade, pull in needed changes from upstream CVS
Line 52: Line 29:
 * Enable ppc64 glibc (ready to upload) === binutils ===
Line 54: Line 31:
 * Upload g++-3.4, building g++ on amd64, defaulting to the new C++ ABI (1002). The current g++-3.4 on amd64 is built for the ABI version 102 to be compatible with g++-3.3 in hoary (libstdc++ having a changed soname).
 * Change "g++" default to 4.0
   * Upload library packages, depending on libstdc++, rename library packages to deal with ABI break, as described on the Transition page.
   * For KDE, only rename libqt, as all other KDE packages depend on this library.
   * Upload all other packages depending on libstdc++, just recompiling, and/or applying outstanding bug reports including patches.
 1. Fix architecture specific bugs.
Line 60: Line 33:
 * Change "gcj", "gij" default to 4.0 If upstream binutils 2.17 is released in 2005, consider an upgrade.
Line 62: Line 35:
 * Add to Breezy release notes intention to drop linuxthreads for remaining arch's. === gcc ===
Line 64: Line 37:
 * Drop gcc-2.95 (also means dropping chill)  1. Move '''gcc-3.3''' sources to universe, just build the libstdc++5 runtime library package from these sources
 2. 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
 3. Convert remaining packages in main from '''g++-3.4''' to '''g++-4.0'''. This depends on upstream bugs fixed in the g++ 4.0 branch.
 4. Update '''gcc-4.0''' to version 4.0.3 when released
Line 66: Line 42:
Post-May TODO: === libstdc++ ===
Line 68: Line 44:
 * Change sparc to nptl-only Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore. (November 2005)
Line 70: Line 46:
 * Look at tweaking gcc wrapper to look for archaic gcc build options (-O6, etc. Possibly do this when HPPA does the Debian import?)  * '''libstdc++6''' is configured to use the mt allocator based on discussions in April 2004 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) in mid-2005. The change does not affect symbols exported from libstdc++, but it does affect symbols exported by libraries which use containers (using an allocator) from the template headers.
 * 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 affected.
Line 72: Line 51:
 * Binutils update (Sparc64 TLS support) === ia32-libs* ===
Line 74: Line 53:
 * Final massive rebuild to make sure that everything is builds correctly.  * Update the '''ia32-libs*''' packages to the current library versions, 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 76: Line 56:
 * Transition for non-release architectures (libgcc on hppa). === gij/gcj-4.1 ===
Line 78: Line 58:
 * Decide which GCC versions to keep for breezy. GCC-4.0 of course, GCC 3.4 for the default g77 and gpc compilers (which are not part of GCC 4.0). Maybe do not build the java, objc, treelang and ada compilers with from 3.4 (but they go to universe anyway). Decide on GCC 3.3. It's still used for the kernel and glibc. If we want to keep the libstdc++5 for compatibility (well, we have at least for packages like Blackdown Java), keep this version as well, maybe reduce things which are built. The Java updates are covered by JavaRoadmap.
Line 80: Line 60:
=== Data Preservation and Migration === === gdb ===
Line 82: Line 62:
glibc update can cause older applications to fail to run. Failures are usually linker-time failures, so low risk of runtime data loss.

=== Packages Affected ===

All packages to some degree:

 * Poorly written C applications that don't work with stricter parser
 * Poorly written C++ applications that don't work with stricter parser
 * Renaming of library packages (about 100 in main, 300 in universe)

=== User Interface Requirements ===

N/A

== Outstanding Issues ==

Coordinating with Debian - confirm that they will follow the same library rename plan.
Proposal sent to debian-release, http://lists.debian.org/debian-release/2005/04/msg00153.html

=== UDU BOF Agenda ===

 * Status update (some work will be done prior to UDU)
 * C++ ABI transition plan (if transitions are still pending)
 * libssp and GCC 4.0 ?

=== UDU Pre-Work ===

 * Transition plan http://www.ubuntulinux.org/wiki/BreezyToolchainTransition
 * Prepare packages of GCC-4.0 (currently in experimental), glibc (Done, uploaded)
 * PowerPC64 biarch support
 * Import of known FTBFS GCC-4.0 reports from unstable, for universe see http://www.ubuntulinux.org/wiki/UniverseCxxTransition (Done)
 * Determine order of library updates
Add support to read 64bit code on ppc and sparc (i386 and amd64 needs checking /jbailey)

Status

Summary

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

Rationale

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

Implementation Plan

glibc

(December 2005)

  1. Merge to the Debian 2.3.5 packages.

If upstream glibc 2.3.6 is released in 2005, consider an upgrade, pull in needed changes from upstream CVS

binutils

  1. Fix architecture specific bugs.

If upstream binutils 2.17 is released in 2005, consider an upgrade.

gcc

  1. Move gcc-3.3 sources to universe, just build the libstdc++5 runtime library package from these sources

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

  3. Convert remaining packages in main from g++-3.4 to g++-4.0. This depends on upstream bugs fixed in the g++ 4.0 branch.

  4. Update gcc-4.0 to version 4.0.3 when released

libstdc++

Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore. (November 2005)

  • libstdc++6 is configured to use the mt allocator based on discussions in April 2004 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) in mid-2005. The change does not affect symbols exported from libstdc++, but it does affect symbols exported by libraries which use containers (using an allocator) from the template headers.

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

ia32-libs*

  • Update the ia32-libs* packages to the current library versions, 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.

gij/gcj-4.1

The Java updates are covered by JavaRoadmap.

gdb

Add support to read 64bit code on ppc and sparc (i386 and amd64 needs checking /jbailey)

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