This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Ports status for 2.11 (was: Re: Will the alpha port be usable for 2.11?)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thomas Orgis <sobukus at sourcemage dot org>
- Cc: libc-ports at sourceware dot org
- Date: Sun, 8 Nov 2009 16:48:53 +0000 (UTC)
- Subject: Ports status for 2.11 (was: Re: Will the alpha port be usable for 2.11?)
- References: <20091108171706.60cfb6dc@sunscreen>
On Sun, 8 Nov 2009, Thomas Orgis wrote:
> Before I go into detail and bore people with my specific build errors,
> which would also probably not be that appropriate for this list, I just
> would like to know if the upcoming glibc ports in version 2.11 is
> supposed to include a working alpha port. I mean one, that works as-is,
Ultimately, it is up to port maintainers to keep their ports working,
including updating them for changes in libc code and reviewing patches
from others to their ports.
Fairly soon we're going to need to tag 2.11 and make the 2.11 branch for
ports. So let's look at the status of ports and what port maintainers
would need to do to bring them up to date for 2.11, and maintainers can
comment on what they might be doing in that regard and when so it can
inform the decision as to when to tag and branch.
* ARM and MIPS are as far as I know fully up to date (including all three
MIPS ABIs). (I have never tested ARM old-ABI and have no information
about whether it still works, although I do not know of any problems with
it either.)
* I haven't tested Power soft-float lately, but I don't know of anything
out-of-date with it.
* M68K has patches pending review to bring it up to date by adding NPTL
support. There's some dependence on kernel patches, although I think the
kernel maintainers did reserve the syscall numbers 333-336 required.
Patches to bring bits/fcntl.h in sync with libc as regards F_GETOWN_EX
etc. are waiting on the kernel resolving problems with the numbering of
those values, at which point most or all architectures will need to update
their settings for these constants (that will presumably happen on 2.11
branch of libc as well as on trunk).
Only the architectures above have an ____longjmp_chk implementation, which
is required for 2.11 to build at all and requires rather more
architecture-specific knowledge to implement than most ports updates for
libc changes do. But these are the other architectures with GNU/Linux
target support in ports, and their status. Getting any of these up to
date would require someone to go through all the sysdeps files, compare
with corresponding libc files and look at logs of changes to those files
since the target moved out of libc. I did that a while ago for m68k
<http://sourceware.org/ml/libc-ports/2008-08/msg00005.html>. Most such
updates - with a few exceptions such as ____longjmp_chk - are reasonably
straightforward and mechanical. Anyone adding ____longjmp_chk
implementations may wish to see my discussion of the logic involved
<http://sourceware.org/ml/libc-ports/2009-08/msg00002.html>.
* Alpha. No maintainer (though RTH may review some patches), needs ports
files updates and ____longjmp_chk implementation.
* HPPA. Maintained by Carlos. Needs ports files updates and
____longjmp_chk implementation. One HPPA bug (6676) is marked with the
glibc_2.11 keyword.
The following architectures do not have an NPTL implementation.
* AM33 (MN10300). No maintainer. Needs ports files updates,
____longjmp_chk and NPTL implementations.
* CRIS. No maintainer. Needs ports files updates, ____longjmp_chk and
NPTL implementations. Unlike AM33, does have TLS support in binutils, but
not in GCC.
I am reluctant to review and apply patches for architectures I know
nothing about; I might consider it for purely mechanical patches to
unmaintained architectures, and review patches for Power soft-float as
well as the architectures I more specifically maintain, but in general if
people are fixing unmaintained architectures they should become
maintainers for those architectures.
--
Joseph S. Myers
joseph@codesourcery.com