EdgyPlusOneToolchainRoadmap

Revision 6 as of 2006-07-03 18:59:14

Clear message

Summary

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

Rationale

Use cases

Scope

Implementation

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

Code

Data preservation and migration

Outstanding issues

  • 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. Is it worth splitting out these compilers (currently gnat-4.1)
  • check how -mtune=generic behaves on amd processors
  • 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.


CategorySpec