> * If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support > that, would it be possible to activate the support on the GLIBC 2.4 branch?
This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version set will never change again. Each platform will either change by the first 2.4 release, or it will not change until the next ABI-changing release (presumably 2.5, and not especially soon). > Given that the GLIBC with the support is fully backwards-compatible with > older GLIBCs, it seems that it would be possible to enable the support > later on the GLIBC 2.4 branch, when compilers that can support the > feature become available. The glibc sources are not the issue. The ABI is the issue. It is easy to make changes at any time that change the ABI, as far as glibc itself is concerned. But every time we change the glibc ABI at all, it is a significant burden on all system makers and by extension on all users. To merely remain backwards compatible with existing binaries, we can define replacement symbols in a newer version set. To do this without muddying the waters terribly for distribution tools and for users, we cannot add anything to a version set that existed in any past releases, but must add a new version set every time the ABI expands to include new versions of some symbols. This is the only way we ever make ABI additions, and the package tools understand it correctly. Even with perfectly well-ordered glibc ABI changes, the mere fact of a change and the introduction of a new version set, is a significant burden on system makers, software binary purveyors for glibc-based systems, and users. (If you are tempted to chip away at the general case I'm describing here, with "but it only affects programs using long double", note that the ABI change moves printf to the new version set on affected platforms.) Any such change means that newly built binaries may require a glibc with the new version set, and thus cannot be installed on any installation of existing OS versions based on glibc 2.4, that have not been upgraded with the new ABI support. For these reasons, the deployment of any new glibc version set is a big deal for everyone concerned with the platform. Thus we have a rather large granularity; 2.4 will be well over a year since the previous glibc ABI was frozen. System makers will stay on one glibc ABI for a long time, it will form the basis of the next round of ABI standards like LSB's, etc. Thanks, Roland