Re: Request for clarification on the 128bit long double requirments

[Roland McGrath <roland at redhat dot com>]

> * 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