EdgyPlusOneToolchainRoadmap

Differences between revisions 6 and 7
⇤ ← Revision 6 as of 2006-07-03 18:59:14 →
Size: 2122
Editor: 0x50c71cc7
Comment:
← Revision 7 as of 2006-07-05 22:25:36 → ⇥
Size: 2517
Editor: 209
Comment: Make slightly more verbose, fill in missing sections, prune empty ones.
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * '''Packages affected''':  * '''Packages affected''': glibc, binutils, gcc.
Line 20: Line 20:
== Use cases == The toolchain needs to be ready as of the openning of the release. Because of this, toolchain changes are sketched out at the beginning of the release, finalised near feature freeze, and uploaded to the archive because merges, syncs and uploads start.
Line 24: Line 24:
The next release of Ubuntu.
Line 26: Line 28:
 * testing: Rebuild a current edgy archive using the proposed toolchain for edgy+1 for all release architectures; requires LP/Soyuz support.

 * powerpc/sparc: glibc/gcc: configure using --enable-long-double-128

 * Upstream versions		  * Update to current upstream versions. As of this writing, we expect these to be:
Line 37: Line 35:
=== Code ===  * Enable long-double-128 support in glibc and gcc on powerpc and sparc.
Line 39: Line 37:
=== Data preservation and migration ===  * Perform test rebuild of the edgy archive against these new toolchain releases.
Line 43: Line 41:
 * removal of compilers for additional languages that should not
   be available in main. just splitting out these compilers drops
   the specs for the gcc driver as well. find a way to build a
   subset of compilers, but keep support for all available compilers
   in the cpp/gcc drivers.		  * In support of reducing the number of packages in main and for reducing build time and complexity for security updates, we want to split additional languages into separate packages. At this point, that causes support to be dropped from the main driver, and causes conflicts. We need to investigate if there is a way around this. If not, this issue can be dropped.
Line 49: Line 43:
   Is it worth splitting out these compilers (currently gnat-4.1)  * -mtune=generic is a new feature in gcc which produces better optimised code on Intel chips. We need to confirm that there are no regressions on 32-bit AMD chips before enabling this.
Line 51: Line 45:
 * check how -mtune=generic behaves on amd processors  * We are often asked for using --as-needed by default. We need to provide documentation on why this isn't enabled by default so that it can be made clear. It would also be useful to setup a "Janitors Team" that would go through and check for text relocations or an excessive number of visible symbols in common libraries and would work with upstreams to make tighter DSOs. This group could also expore using --as-needed and linker optimisation as well.
Line 53: Line 47:
 * check time frame for glibc-2.5

== BoF agenda and discussion ==

 * How does this stand with enabling --as-needed linking in Edgy+1?
 It would greatly decrease the loadtimes for applications not to mention make the linker work the way it should. I have tried linking a basic system using this option using Gentoo and there are very few issues, it would definately be worth considering enabling it at some point in the near future.

Summary

Plans for the toolchain to be ready when Edgy+1 opens the archives

Rationale

The toolchain needs to be ready as of the openning of the release. Because of this, toolchain changes are sketched out at the beginning of the release, finalised near feature freeze, and uploaded to the archive because merges, syncs and uploads start.

Scope

The next release of Ubuntu.

Implementation

  • Update to current upstream versions. As of this writing, we expect these to be:
    • glibc-2.4.x
    • binutils-2.17.x
    • gcc-4.2.x
      • tune with -mtune=generic by default
    • gcj-4.2.x, follow the development of the ecj branch for 1.5 language and runtime features
  • Enable long-double-128 support in glibc and gcc on powerpc and sparc.
  • Perform test rebuild of the edgy archive against these new toolchain releases.

Outstanding issues

  • In support of reducing the number of packages in main and for reducing build time and complexity for security updates, we want to split additional languages into separate packages. At this point, that causes support to be dropped from the main driver, and causes conflicts. We need to investigate if there is a way around this. If not, this issue can be dropped.
  • -mtune=generic is a new feature in gcc which produces better optimised code on Intel chips. We need to confirm that there are no regressions on 32-bit AMD chips before enabling this.
  • We are often asked for using --as-needed by default. We need to provide documentation on why this isn't enabled by default so that it can be made clear. It would also be useful to setup a "Janitors Team" that would go through and check for text relocations or an excessive number of visible symbols in common libraries and would work with upstreams to make tighter DSOs. This group could also expore using --as-needed and linker optimisation as well.

CategorySpec

EdgyPlusOneToolchainRoadmap (last edited 2008-08-06 16:37:41 by localhost)