This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Ports status for 2.11 (was: Re: Will the alpha port be usable for 2.11?)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]