EdgyToolchainRoadmap
2933
Comment: Comments
|
2803
feedback after review
|
Deletions are marked like this. | Additions are marked like this. |
Line 10: | Line 10: |
{{{ tfheen: general comment: please use full sentences and be a bit more verbose. }}} * Versions targeted. {{{ tfheen: Which versions? }}} * Multiarch integration / biarch updates {{{ tfheen: Change to "Multiarch integration postponed" or something along those lines? }}} * Defaults for Stack Protection {{{ tfheen: "Enable stack protection by default" }}} |
* Name the versions of affected packages targeted for edgy. * Multiarch integration not a hard goal for edgy, may be postponed for edgy+1. * Updates for the biarch setup. * Enable stack protection by default |
Line 31: | Line 20: |
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). | Edgy has a short release cycle, use edgy as a testbed for one major change (stack protection), but keep the rest of the toolchain rather un-edgy and use the time to prepare a solid work for edgy+1 (EdgyPlusOneToolchainRoadmap). |
Line 34: | Line 23: |
{{{ doko: I don't have a longer rationale. }}} | |
Line 42: | Line 32: |
{{{ doko: hppa is a community arch, no explicit action is taken; maybe same situation with db4.3 on hppa dapper }}} | |
Line 43: | Line 34: |
* details can be found in GccSsp {{{ tfheen: details for what; please reword? }}} |
* Details for enabling of StackProtection can be found in GccSsp |
Line 55: | Line 44: |
* on sparc, build a sparc64-linux-gnu compiler defaulting to sparc-linux-gnu by default (requested by the sparc port). {{{ tfheen: is a sparc64-linux-gnu compiler a compiler whose host is sparc64-linux-gnu or whose target is sparc64-linux-gnu ? }}} |
* on sparc, build a sparc64-linux (host) to sparc-linux/sparc64-linux compiler (target) defaulting to sparc-linux by default (requested by the sparc port). |
Line 62: | Line 48: |
* Demoting compilers to universe, which are not necessarily needed for main (See outstanding issues). {{{ tfheen: outstanding issues is empty. }}} |
* Demoting compilers to universe, which are not necessarily needed for main (moved to edgy+1, optional target for edgy). |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/edgy-toolchain-roadmap
Created: Date(2006-06-09T12:55:47Z) by MatthiasKlose
Contributors: MatthiasKlose, JeffBailey
Packages affected: gcc*, gcj*, glibc, binutils
Summary
- Name the versions of affected packages targeted for edgy.
- Multiarch integration not a hard goal for edgy, may be postponed for edgy+1.
- Updates for the biarch setup.
- Enable stack protection by default
- 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 (stack protection), but keep the rest of the toolchain rather un-edgy and use the time to prepare a solid work for edgy+1 (EdgyPlusOneToolchainRoadmap).
tfheen: a bit more verbosity would be good. doko: I don't have a longer rationale.
Implementation
- NPTL is enabled and the default in glibc-2.4, linuxthreads not enabled anymore
- all release architectures and ia64 supported
- hppa certainly broken
tfheen: What's the plan for fixing hppa? doko: hppa is a community arch, no explicit action is taken; maybe same situation with db4.3 on hppa dapper
Details for enabling of StackProtection 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 (host) to sparc-linux/sparc64-linux compiler (target) defaulting to sparc-linux 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 (moved to edgy+1, optional target for edgy).
- 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
EdgyToolchainRoadmap (last edited 2008-08-06 16:38:55 by localhost)