EdgyToolchainRoadmap

Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2006-06-22 15:38:43 →
Size: 3094
Editor: ALagny-109-1-9-136
Comment: multiarch update
← Revision 4 as of 2006-06-22 17:16:53 → ⇥
Size: 3055
Editor: ALagny-109-1-2-101
Comment: Slight cleanups, a comment
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:

 Describe our plans with the toolchain
Line 22: Line 20:

== Use cases ==

== Scope ==
Line 52: Line 46:
=== Code ===

=== Data preservation and migration ===		 {{{ jbailey: What actually needs to be done on this, or is this spec just informational? }}}

Summary

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

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 (pending approval in GccSsp).

    • 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
    • no multiarch changes explicitely targeted for edgy, see if glibc, gcc, binutils can be changed to transparently install in multiarch locations.
    • 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

 jbailey: What actually needs to be done on this, or is this spec just informational? 

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

EdgyToolchainRoadmap (last edited 2008-08-06 16:38:55 by localhost)