ToolchainRoadmap
Differences between revisions 23 and 25 (spanning 2 versions)
|
Size: 4484
Comment: note about ppc64 power3/power4 kernels so that we don't forget.
|
Size: 3029
Comment: add ia32-libs stuff/libstdc++/g++-3.4 stuff
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| * Created: [[Date(2005-04-24T00:11:33Z)]] by MattZimmerman[[BR]] | * Created: 2005-11-02 by MatthiasKlose[[BR]] |
| Line 10: | Line 10: |
| * People: MatthiasKloseLead, JeffBaileySecond[[BR]] * Contributors: MattZimmerman[[BR]] * Interested: JimMcQuillan [[BR]] * Status: BreezyGoal, DistroSpecification, ApprovedSpecification * Packages: [[BR]] * Depends: [[BR]] * UduSessions: 1(0) [[BR]] |
* People: MatthiasKlose, JeffBailey[[BR]] * Packages: glibc, binutils, gcc, ia32-libs[[BR]] |
| Line 18: | Line 13: |
| == Introduction == | == Summary == |
| Line 20: | Line 15: |
| Review toolchain status and strategy for Breezy | 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 |
| Line 24: | Line 19: |
| * Much improved Java support * Better error reporting from C and C++ front-end * LSB 3.0 support * Fortran 90 support * Better optimizations from C compiler * Faster compilation at -O0 * Better standards compliance == Scope and Use Cases == * gcc-4.0 * g++-4.0 and associated ABI transition * glibc 2.3.5 |
We do not want to introduce new upstream versions in the dapper time frame, just fixing bugs in the existing toolchain packages. |
| Line 40: | Line 23: |
| * Details at http://www.ubuntulinux.org/wiki/BreezyToolchainTransition Already done: * Change "gcc" default to 4.0 * Change "g77" default to 3.4 * change "cpp" default to 4.0 * Upload glibc-2.3.5 * Change powerpc, ia64 to nptl-only May TODO: * Enable ppc64 glibc (ready to upload) * Upload g++-3.4, building g++ on amd64, defaulting to the new C++ ABI (1002). The current g++-3.4 on amd64 is built for the ABI version 102 to be compatible with g++-3.3 in hoary (libstdc++ having a changed soname). * Change "g++" default to 4.0 * Upload library packages, depending on libstdc++, rename library packages to deal with ABI break, as described on the Transition page. * For KDE, only rename libqt, as all other KDE packages depend on this library. * Upload all other packages depending on libstdc++, just recompiling, and/or applying outstanding bug reports including patches. * Change "gcj", "gij" default to 4.0 * Add to Breezy release notes intention to drop linuxthreads for remaining arch's. * Drop gcc-2.95 (also means dropping chill) Post-May TODO: * Change sparc to nptl-only * Look at tweaking gcc wrapper to look for archaic gcc build options (-O6, etc. Possibly do this when HPPA does the Debian import?) * Binutils update (Sparc64 TLS support) * Final massive rebuild to make sure that everything is builds correctly. * Transition for non-release architectures (libgcc on hppa). * Decide which GCC versions to keep for breezy. GCC-4.0 of course, GCC 3.4 for the default g77 and gpc compilers (which are not part of GCC 4.0). Maybe do not build the java, objc, treelang and ada compilers with from 3.4 (but they go to universe anyway). Decide on GCC 3.3. It's still used for the kernel and glibc. If we want to keep the libstdc++5 for compatibility (well, we have at least for packages like Blackdown Java), keep this version as well, maybe reduce things which are built. === Data Preservation and Migration === glibc update can cause older applications to fail to run. Failures are usually linker-time failures, so low risk of runtime data loss. === Packages Affected === All packages to some degree: * Poorly written C applications that don't work with stricter parser * Poorly written C++ applications that don't work with stricter parser * Renaming of library packages (about 100 in main, 300 in universe) === User Interface Requirements === N/A |
* 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. |
| Line 98: | Line 39: |
| Coordinating with Debian - confirm that they will follow the same library rename plan. Proposal sent to debian-release, http://lists.debian.org/debian-release/2005/04/msg00153.html Note that, once we have a ppc64 biarch toolchain and build ppc64 kernels, we can drop the separate power3 and power4 kernels that currently take up a lot of CD space; apparently ppc64 kernels can include support for both CPU types in a single config. === UDU BOF Agenda === * Status update (some work will be done prior to UDU) * C++ ABI transition plan (if transitions are still pending) * libssp and GCC 4.0 ? === UDU Pre-Work === * Transition plan http://www.ubuntulinux.org/wiki/BreezyToolchainTransition * Prepare packages of GCC-4.0 (currently in experimental), glibc (Done, uploaded) * PowerPC64 biarch support * Import of known FTBFS GCC-4.0 reports from unstable, for universe see http://www.ubuntulinux.org/wiki/UniverseCxxTransition (Done) * Determine order of library updates |
* 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) this summer. The change does not effect symbols exported from libstdc++, but libraries, which use containers from the template headers, using a allocator. 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 effected. |
Toolchain Roadmap
Status
Created: 2005-11-02 by MatthiasKloseBR
Priority: HighPriorityBR
People: MatthiasKlose, JeffBaileyBR
Packages: glibc, binutils, gcc, ia32-libsBR
Summary
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
Rationale
We do not want to introduce new upstream versions in the dapper time frame, just fixing bugs in the existing toolchain packages.
Implementation Plan
- 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.
Outstanding Issues
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) this summer. The change does not effect symbols exported from libstdc++, but libraries, which use containers from the template headers, using a allocator. 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 effected.
ToolchainRoadmap (last edited 2008-08-06 16:34:44 by localhost)