Re: Moving ports architectures to libc?

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

On Wed, 22 Jan 2014, Carlos O'Donell wrote:

> > * The architecture maintainer does the move for their architecture and 
> > verifies that, for at least one configuration for the given architecture, 
> > the disassembly of the installed shared libraries is the same before and 
> > after the move.  (Thus, the port needs to build, unmodified, before the 
> > move, which I think would exclude am33 and hppa from moving at present.  
> > It does not need to be fully up to date with global changes - it may have 
> > entries in <https://sourceware.org/glibc/wiki/PortStatus> - although I 
> > certainly encourage maintainers to fix such issues either before or after 
> > the move.)
> 
> I disagree about hppa, I have patches, and I can do the move myself and
> verify that it still builds afterwards?

I'm generally dubious about the long-term presence of ports in the tree 
that don't work without external patches, or that are too far behind on 
updates for global changes.  The patches required to get hppa into a 
working state should be submitted and pinged just like any other patches - 
the patch to NPTL for stacks growing up (as attached to 
<https://sourceware.org/glibc/wiki/Release/2.17>) really isn't that big or 
complicated, and you can just check in changes to the 
architecture-specific code.

(The same applies to Hurd, where I believe there are large pieces like TLS 
not checked in.  A TLS patch dated 2009 was posted in 2012 
<https://sourceware.org/ml/libc-alpha/2012-05/msg00725.html>, and I see no 
pings since then, while the contribution checklist indicates weekly pings.  
If 50 patches (that already exist) are needed to get Hurd working, send 50 
patches, and then 50 weekly pings as needed until all significant 
functionality is reviewed and checked in.  But the criterion I'm 
suggesting for moving a port to libc is the weaker "builds unmodified" - I 
don't know how far Hurd is from that - rather than "functionality matches 
the versions used in practice" or "ABI matches the versions used in 
practice, and there are ABI test baselines".  For the ABI point SH also 
has an issue: the unresolved issue for __fpscr_values discussed in 
<https://sourceware.org/ml/libc-alpha/2012-05/msg01988.html>.)

I'd like to see build bots building all the enumerated ABI variants (and 
beyond that, CPU variants to cover the different optimized versions of 
functions present in glibc) - and while running the tests from such bots 
would be good (I think - no-one has actually shown interest in my 
prerequisite patch series 
<https://sourceware.org/ml/libc-alpha/2014-01/msg00192.html> to generate 
PASS / FAIL test results summaries), the basic minimum is that each 
variant actually builds for unmodified glibc.

-- 
Joseph S. Myers
joseph@codesourcery.com