ABI freeze for GLIBC_2.4

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

ABI freeze for GLIBC_2.4

Roland McGrath
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

Reply | Threaded
Open this post in threaded view
|

Re: ABI freeze for GLIBC_2.4

Dwayne Grant McConnell-2
On Wed, 4 Jan 2006, Roland McGrath wrote:

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

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

Are there specific items I can do to help with ppc[64]?

--
Dwayne Grant McConnell <[hidden email]>
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS

Reply | Threaded
Open this post in threaded view
|

Re: ABI freeze for GLIBC_2.4

Jeff Bailey-5
In reply to this post by Roland McGrath
Le mercredi 04 janvier 2006 à 12:30 -0800, Roland McGrath a écrit :
> 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.

I do most of the maintenance for the Ubuntu glibc packages.  Our current
development release (Dapper) is going to release with 2.3.6 in April.
Somewhere on my TODO list is "figure out if we should try for 2.4 for
the October release".

Based on this freeze, a 2.4-based glibc should enter our development
repository at the end of April.

Tks,
Jeff Bailey

* Canonical Ltd * Ubuntu Service and Support * +1 514 691 7221 *

Linux for Human Beings.


Reply | Threaded
Open this post in threaded view
|

Re: ABI freeze for GLIBC_2.4

Andreas Jaeger
In reply to this post by Roland McGrath
Roland McGrath <[hidden email]> writes:

> [...]
> 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.

We just switched to glibc 2.4 CVS for SUSE Linux as well - our
openSUSE factory distribution is already build against glibc 2.4.  The
first test results look fine,

Andreas
--
 Andreas Jaeger, [hidden email], http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ABI freeze for GLIBC_2.4

Andrew Pinski
In reply to this post by Roland McGrath
> * 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.

I am not happy this part of the ABI freeze.  It is putting too much stress on
getting a GCC 4.1 compiler which has this change as GCC 4.1.0 was supposed
to be have been ABI (except for regression fixes) at the end of stage 2 which
ended April 25 2005, a long before this discussion to freeze glibc's 2.4 ABI
was decided.

Someone over in the glibc land should have send a heads up about this issue
long before the problem of getting a glibc 2.4 ABI freezen and GCC 4.1.0 was
even supposed to be released.  The glibc should have taken into account GCC's
release and maybe asked if this would be okay with them but there was none so
now there is caos in trying to patch GCC 4.1.0 before the release.

Thanks,
Andrew Pinski