EdgyToolchainRoadmap

Revision 2 as of 2006-06-22 09:58:09

Clear message

Summary

  • Describe our plans with the toolchain
  • Versions targeted.
  • Multiarch integration / biarch updates
  • Defaults for Stack Protection
  • Drop obsolete compiler packages

Separate specs are GccSsp and JavaRoadmap.

Rationale

Edgy has a short release cycle, use edgy as a testbed for one major change, but keep the rest of the toolchain rather un-edgy and use the time to prepare a solid work for edgy+1 (EdgyPlusOneToolchainRoadmap).

Use cases

Scope

Design

  • NPTL is enabled and the default in glibc-2.4.
    • all release architectures and ia64 supported
    • hppa probably broken

  • details can be found in GccSsp

    • turn on -fstack-protector and see what happens.
    • prepare a more solid solution for edgy+1
    • provide some kind of documentation / tutorial; not much included upstream
    • Add libssp0-dev as a dependency of gcc-4.1, or merge it into gcc-4.1.
  • multiarch/biarch related changes
    • don't add anything multiarch specific for edgy.
    • biarch -m32/-m64 changes (See outstanding issues)
  • Demoting compilers to universe, which are not necessarily needed for main (See outstanding issues).
  • upstream tools
    • glibc-2.4, in edgy.
    • binutils-2.17, needs testing and packaging, not yet available in unstable.
    • gcc-4.1.1, gcc-4.1.2 likely after edgy freeze; follow the 4.1 branch to some point, then apply patches for wrong-code/ice-on-valid failures.

Implementation

Code

Data preservation and migration

Outstanding issues

  • biarch -m32/-m64 changes
    • currently the system compiler knows about the second architecture, this support is available by configuring the compiler with multilib support. current behaviour is to search the include directories proposed by multiarch, library search paths need to be done.
    • do not build biarch compilers, let the the compiler driver call the normal compiler provided from the multiarch architecture when the driver is called with -m32 / -m64. Recommended (?, done by Fedora/Suse) on some platforms; upstream only "supports" powerpc/powerpc64; i486/x86_64, x86_64/i486, sparc/sparc64 are patched for our distribution.
  • 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)

BoF agenda and discussion

CategorySpec