EdgyToolchainRoadmap
764
Comment: add page
|
3094
multiarch update
|
Deletions are marked like this. | Additions are marked like this. |
Line 5: | Line 5: |
* '''Contributors''': MatthiasKlose | * '''Contributors''': MatthiasKlose, JeffBailey |
Line 10: | Line 10: |
Desribe our plans with the toolchain | Describe our plans with the toolchain |
Line 12: | Line 12: |
* Versions targeted (mostly fixed, need to decide about Java 4.1/4.2) * Multiarch integration? |
* Versions targeted. * Multiarch integration / biarch updates |
Line 17: | Line 17: |
Separate specs are GccSsp and JavaRoadmap. |
|
Line 18: | 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). |
|
Line 24: | Line 28: |
* 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. |
|
Line 33: | Line 58: |
* 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) |
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
- 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 (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
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
EdgyToolchainRoadmap (last edited 2008-08-06 16:38:55 by localhost)