ToolchainRoadmap
|
Size: 3407
Comment: update from feedback
|
← Revision 38 as of 2008-08-06 16:34:44 ⇥
Size: 3337
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| = Toolchain Roadmap = |
|
| Line 8: | Line 6: |
| * Created: 2005-11-02 by MatthiasKlose[[BR]] * Priority: HighPriority[[BR]] * People: MatthiasKlose, JeffBailey[[BR]] * Packages: glibc, binutils, gcc, ia32-libs[[BR]] |
* Created: 2005-11-02 by MatthiasKlose<<BR>> * People: MatthiasKlose, JeffBailey<<BR>> * Packages: glibc, binutils, gcc, ia32-libs<<BR>> * Launchpad: https://launchpad.net/distros/ubuntu/+spec/toolchain-roadmap |
| Line 15: | Line 13: |
| Upgrade the toolchain to new minor/subminor versions. Maybe upgrade gij/gcj to a recent version (4.1), if needed for Edubuntu. Change libstdc++ configuration to use the new | Upgrade the toolchain to new minor/subminor versions. Consider an upgrade for gij/gcj to a recent version (4.1), if needed for Edubuntu. Change libstdc++ configuration to use the new allocator. |
| Line 23: | Line 21: |
| * glibc: * merge to the Debian 2.3.5 packages. If 2.3.6 is released in 2005, consider an upgrade * binutils: * fix architecture specific bugs. If 2.17 is released in 2005, consider an upgrade. * gcc: * Move gcc-3.3 sources to universe, just build the libstdc++5 runtime library package from these sources * keep gcc-3.4 (upstream glibc-2.3.x cannot be built with 4.0 without patches, upstream asks for a g77 compiler as long as gfortran isn't mature enough, pascal is built by gcc-3.4 only, but universe anyway). Update to gcc-3.4.5 when released * Try to avoid using g++-3.4 for main, depends on upstream bugs fixed in g++-4.0. * Update gcc-4.0 to gcc-4.0.3 when released * libstdc++: Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore. Needs some work, see below. Should be done as soon as the effected packages are known. * ia32-libs*: * Update ia32-libs* to the current library versions (missed for breezy), drop the libraries which can be built from the source packages and where we already build lib64 packages, and build lib32 packages instead (November 2005). * if OOo is built natively for amd64, drop most of ia32-libs. Do not care about ia32-libs for ia64. If necessary, provide a cross toolchain for ia64 (ia64->i386) to build the required libraries (done for binutils and gcc, needs work for glibc), very low priority. |
=== glibc === |
| Line 37: | Line 23: |
| == Outstanding Issues == | (December 2005) |
| Line 39: | Line 25: |
| * Decide on a glibc update (when, to which version) (JeffBailey) * libstdc++6 is configured to use the mt allocator based on discussions with upstream libstdc++ developers. This configuration turned out to be a mistake (memory leaks and still buggy), other distributions did change back to the new allocator (the default one) in mid-2005. The change does not affect symbols exported from libstdc++, but it does affect symbols exported by libraries which use containers (using an allocator) from the template headers. What needs to be done: * Configure libstdc++ to use the new allocator. * Identify all library packages depending on libstdc++ and exporting *mt_alloc* symbols. * rebuild these libraries and depending packages. Note that partial upgrades won't work with this procedure. To make this work, we would have to change the package name for all libraries affected. |
1. Merge to the Debian 2.3.5 packages. |
| Line 46: | Line 27: |
| * Decide on shipping gij/gcj-4.1. gcj/gij will have an updated classpath library which has a more complete implementation for many APIs. Not strictly needed for building the existing java stuff in main, but requested in bug reports. Evaluate if adding the new gij/gcj without adding an updated gcc/g++ is possible. | If upstream glibc 2.3.6 is released in 2005, consider an upgrade, pull in needed changes from upstream CVS === binutils === 1. Fix architecture specific bugs. If upstream binutils 2.17 is released in 2005, consider an upgrade. === gcc === 1. Move '''gcc-3.3''' sources to universe, just build the libstdc++5 runtime library package from these sources 2. keep '''gcc-3.4''' (upstream glibc-2.3.x cannot be built with 4.0 without patches, upstream asks for a g77 compiler as long as gfortran isn't mature enough, pascal is built by '''gcc-3.4''' only, but universe anyway). Update to gcc-3.4.5 when released 3. Convert remaining packages in main from '''g++-3.4''' to '''g++-4.0'''. This depends on upstream bugs fixed in the g++ 4.0 branch. 4. Update '''gcc-4.0''' to version 4.0.3 when released === libstdc++ === Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore. (November 2005) * '''libstdc++6''' is configured to use the mt allocator based on discussions in April 2004 with upstream libstdc++ developers. This configuration turned out to be a mistake (memory leaks and still buggy), other distributions did change back to the new allocator (the default one) in mid-2005. The change does not affect symbols exported from libstdc++, but it does affect symbols exported by libraries which use containers (using an allocator) from the template headers. * Configure libstdc++ to use the new allocator. * Identify all library packages depending on libstdc++ and exporting *mt_alloc* symbols. * rebuild these libraries and depending packages. Note that partial upgrades won't work with this procedure. To make this work, we would have to change the package name for all libraries affected. === ia32-libs* === * Update the '''ia32-libs*''' packages to the current library versions, drop the libraries which can be built from the source packages and where we already build lib64 packages, and build lib32 packages instead (November 2005). * if OOo is built natively for amd64, drop most of ia32-libs. Do not care about ia32-libs for ia64. If necessary, provide a cross toolchain for ia64 (ia64->i386) to build the required libraries (done for binutils and gcc, needs work for glibc), very low priority. === gij/gcj-4.1 === The Java updates are covered by JavaRoadmap. === gdb === Add support to read 64bit code on ppc and sparc (i386 and amd64 needs checking /jbailey) |
Status
Created: 2005-11-02 by MatthiasKlose
People: MatthiasKlose, JeffBailey
Packages: glibc, binutils, gcc, ia32-libs
Launchpad: https://launchpad.net/distros/ubuntu/+spec/toolchain-roadmap
Summary
Upgrade the toolchain to new minor/subminor versions. Consider an upgrade for gij/gcj to a recent version (4.1), if needed for Edubuntu. Change libstdc++ configuration to use the new allocator.
Rationale
We do not want to introduce new major upstream versions and unknown bugs in the dapper time frame, just fix bugs in the existing toolchain packages.
Implementation Plan
glibc
(December 2005)
- Merge to the Debian 2.3.5 packages.
If upstream glibc 2.3.6 is released in 2005, consider an upgrade, pull in needed changes from upstream CVS
binutils
- Fix architecture specific bugs.
If upstream binutils 2.17 is released in 2005, consider an upgrade.
gcc
Move gcc-3.3 sources to universe, just build the libstdc++5 runtime library package from these sources
keep gcc-3.4 (upstream glibc-2.3.x cannot be built with 4.0 without patches, upstream asks for a g77 compiler as long as gfortran isn't mature enough, pascal is built by gcc-3.4 only, but universe anyway). Update to gcc-3.4.5 when released
Convert remaining packages in main from g++-3.4 to g++-4.0. This depends on upstream bugs fixed in the g++ 4.0 branch.
Update gcc-4.0 to version 4.0.3 when released
libstdc++
Configure with the new allocator (the default), upstream doesn't recommend using the mt allocator anymore. (November 2005)
libstdc++6 is configured to use the mt allocator based on discussions in April 2004 with upstream libstdc++ developers. This configuration turned out to be a mistake (memory leaks and still buggy), other distributions did change back to the new allocator (the default one) in mid-2005. The change does not affect symbols exported from libstdc++, but it does affect symbols exported by libraries which use containers (using an allocator) from the template headers.
- Configure libstdc++ to use the new allocator.
- Identify all library packages depending on libstdc++ and exporting *mt_alloc* symbols.
- rebuild these libraries and depending packages. Note that partial upgrades won't work with this procedure. To make this work, we would have to change the package name for all libraries affected.
ia32-libs*
Update the ia32-libs* packages to the current library versions, drop the libraries which can be built from the source packages and where we already build lib64 packages, and build lib32 packages instead (November 2005).
if OOo is built natively for amd64, drop most of ia32-libs. Do not care about ia32-libs for ia64. If necessary, provide a cross toolchain for ia64 (ia64->i386) to build the required libraries (done for binutils and gcc, needs work for glibc), very low priority.
gij/gcj-4.1
The Java updates are covered by JavaRoadmap.
gdb
Add support to read 64bit code on ppc and sparc (i386 and amd64 needs checking /jbailey)
ToolchainRoadmap (last edited 2008-08-06 16:34:44 by localhost)