ABI freeze for GLIBC_2.4

[Roland McGrath <roland at redhat dot com>]

The trunk is getting mature, and a 2.4 release is starting to be visible on
the horizon.  There is lots more to be done, but it has gotten to be time
to freeze the ABI for glibc 2.4.  (I'm not talking about a code freeze--we
have plenty more work to be done before that.  I'll be posting more shortly
on other topics that need to be addressed before a code freeze and a
release can follow.  Please keep replies on this thread directly apropos to
the subject of the ABI freeze.)

I'd like to declare the ABI freeze for 2.4 and the closure of the GLIBC_2.4
version set for new symbols next week, January 9th.  This does not
necessarily mean everything will be in place on Monday, but any changes
should be agreed upon by then.  If I don't know about it by the end of this
week, do not expect to see it in the GLIBC_2.4 ABI.  If there is anything
you have asked for in the past, or have been wanting to see in the next
glibc ABI version, now is the time.  This is not really open to random new
feature requests.  If your proposal isn't already pretty firmly laid out and
likely to be agreed to on its merits, then don't expect it to happen now.
If there is something that was discussed in the past and had some consensus
but never went in, bring it up right now.

There are a few items not yet in the tree that I expect to be added before
the hard ABI freeze.  These are:

* additional *at functions (?)
  I think we have all these covered already.
  But if there are any more that anyone is going to want, now is the time.

* additional __*_chk entry points (_FORTIFY_SOURCE)
  Ulrich has done several rounds of adding these already, and we don't off
  hand know of more we'd like to cover.  Ideally we'll manage an exhaustive
  audit of the functions in the ABI to cover any and all remaining
  functions taking pointers to user buffers that could be protected from
  erroneous overruns by the _FORTIFY_SOURCE/__builtin_object_size magic.

* long double type switchover for ppc, sparc32, alpha, s390, others(?)
  Patches for this are around and need to be updated and merged, and I've
  committed to helping with that soon.  Each and every architecture
  maintainer should check that the long double type is defined in the most
  desireable way on their architecture and that the gcc and glibc support
  is aligned.  We will not be happy about doing this again later for other
  machines.

A reminder of what we mean by "ABI freeze": the part of the ABI represented
by GLIBC_2.3.4 and older version sets is already frozen; this means that no
symbols can be added or removed to these sets, and the well-defined meanings
of the types and behaviors associated with symbols cannot change such that
applications previously built observing the specified API at the time now
fail to work as they were specified to then.  The GLIBC_2.4 ABI is so far
not frozen, meaning that all the symbols in it are subject to change.  By
the policy I've posted here in the past, well-behaved organizations that
distribute binaries based on glibc do not use unfrozen version set names in
any operating system distribution release for general use or in any version
not labelled as a test version subject to change and without ABI guarantees.
Once the ABI is frozen, then people making binaries are welcome and
encouraged to build libraries and applications using that ABI and test it as
heavily as possible.  The ABI freeze does not completely guarantee that
nothing will change.  It means that the only changes will be corrections of
any unintended details found during the testing.  It's only when we actually
make the 2.4 release that we try to absolutely guarantee that the GLIBC_2.4
ABI will never change again.  Hopefully there aren't any changes after the
stated freeze, and it will become clear during the testing (which has
already started now) when we're confident that no changes will be required.

Jakub, Ulrich, and I are involved in the development of Fedora Core.
Current development/test versions of Fedora Core are already using the trunk
code with GLIBC_2.4 version set.  This system is in pre-release state and
its ABIs still subject to change, but it is already giving pretty heavy
testing to the current glibc code (compiled with GCC 4.1).  If you are
working on another system or project that is now or will soon be testing
glibc binaries with the GLIBC_2.4 set based on the trunk code, please tell
us about it here on the mailing list.


Thanks,
Roland