Re: Glibc release check-list

["Joseph S. Myers" <joseph at codesourcery dot com>]

[removing libc-alpha from this discussion]

On Sat, 14 Nov 2009, Carlos O'Donell wrote:

> On Sat, Nov 14, 2009 at 5:10 AM, Alfred M. Szmidt <ams@gnu.org> wrote:
> > ? The ports repository still needs tagging/branching, but that can come
> > ? a little later.
> >
> > Who actually takes care of that? And when is ports in a state that it
> > should be tagged?
> 
> I requested that ports tagging be delayed to allow me time to fix
> several hppa defects.
> 
> Since then I have discovered that the correction of these defects
> requires patches to core glibc for cases where the stack grows up (not
> down).
> 
> Having a fixed ports but a broken glibc core isn't useful, therefore I
> no longer oppose the tagging/branching of ports to 2.11.
> 
> However, I believe that m68k is also missing a ____longjmp_chk
> implementation and that the tagging of ports was being delayed for
> this fix. I can't speak for m68k since I don't maintain that machine
> architecture.

m68k is not missing ____longjmp_chk.  It's missing NPTL (I don't know if 
this is lack of time for review, or waiting for the kernel changes to be 
reviewed there first), which includes a symbol at GLIBC_2.11 version, and 
bits/fcntl.h changes which break the build for other reasons.  Fixes to 
the values in bits/fcntl.h have gone into the kernel and into libc (I 
presume those will be cherry-picked to 2.11 branch of libc) so I'll update 
ARM and MIPS and prepare a new update for M68K ... but there are kernel 
patches flying around to change those values again.

hppa *is* missing ____longjmp_chk, and a fallocate64 export which would 
also go at GLIBC_2.11 version.

If we branch 2.11 now, neither hppa nor m68k (nor alpha) will work at 2.11 
branchpoint.  I suppose this does mean we can reasonably say that no ABI 
is yet defined for hppa or m68k for 2.11 and so the addition of symbols at 
2.11 version can go on 2.11 branch for those targets.

There is a good reason to branch 2.11 for ports now: libc now has 2.12 
versions because of the addition of a new errno value.  If I understand 
the errlist-compat mechanism correctly, the increase in the maximum errno 
value will require errlist-compat updates for alpha and hppa when their 
bits/errno.h headers are updated - but no change will be needed for MIPS 
(EDQUOT is 1133 there while ERFKILL is 167 so the maximum value has not 
increased).  (My understanding would also suggest that the libc 
sysdeps/unix/sysv/linux/sparc/Versions needs updating, although the libc 
commit updated the SPARC bits/errno.h without changing the Versions file.)

So my inclination is to do the bits/fcntl.h updates then branch ports, 
while allowing the fixes for m68k and hppa (and alpha ____longjmp_chk or 
other sysdeps updates) to go on 2.11 branch of ports once ready.

-- 
Joseph S. Myers
joseph@codesourcery.com