EdgyToolchainRoadmap

Differences between revisions 4 and 5
⇤ ← Revision 4 as of 2006-06-22 17:16:53 →
Size: 3055
Editor: ALagny-109-1-2-101
Comment: Slight cleanups, a comment
← Revision 5 as of 2006-06-23 09:24:21 → ⇥
Size: 2306
Editor: ALagny-109-1-2-101
Comment: multiarch additions
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
== Design == == Implementation ==
Line 23: Line 23:
 * NPTL is enabled and the default in glibc-2.4.  * NPTL is enabled and the default in glibc-2.4, linuxthreads not enabled anymore
Line 25: Line 25:
   * hppa probably broken    * hppa certainly broken
Line 35: Line 35:
   * biarch -m32/-m64 changes (See outstanding issues)    * biarch -m32/-m64 changes (See as well outstanding issues / discussion below)
     * on sparc, build a sparc64-linux-gnu compiler defaulting to sparc-linux-gnu by default (requested by the sparc port).
     * for i386, build a non-biarch compiler, plus a i386->amd64 cross compiler, which still can be called using gcc -m64.
   * provide <triplet>-<tool> wrappers for the biarch compilers.
Line 44: Line 47:
== Implementation ==

{{{ jbailey: What actually needs to be done on this, or is this spec just informational? }}}
Line 49: Line 48:

 * 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)

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

Implementation

  • NPTL is enabled and the default in glibc-2.4, linuxthreads not enabled anymore
    • all release architectures and ia64 supported
    • hppa certainly 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 as well outstanding issues / discussion below)
      • on sparc, build a sparc64-linux-gnu compiler defaulting to sparc-linux-gnu by default (requested by the sparc port).

      • for i386, build a non-biarch compiler, plus a i386->amd64 cross compiler, which still can be called using gcc -m64.

    • provide <triplet>-<tool> wrappers for the biarch compilers.

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

Outstanding issues

BoF agenda and discussion

CategorySpec

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