EdgyPlusOneToolchainRoadmap
Revision 6 as of 2006-07-03 18:59:14
Clear message
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/edgyplusone-toolchain-roadmap
Created: Date(2006-06-09T13:02:04Z) by MatthiasKlose
Contributors: MatthiasKlose DavidNielsen2
Packages affected:
Summary
Plans for the toolchain to be ready when Edgy+1 opens the archives
- Have a tested toolchain ready for edgy+1
- ABI changes/change of default options
- Upstream versions
Interaction with gcc-ssp spec (https://launchpad.net/distros/ubuntu/+spec/gcc-ssp)
Implement changes deferred from EdgyToolchainRoadmap.
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.