Re: make nptl no longer an add-on?

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

On Thu, 8 May 2014, Roland McGrath wrote:

> In practice today nobody ever builds the Linux configurations without nptl.
> Doing so requires --disable-sanity-checks, and produces a library that has
> an ABI incompatible with production builds.  So I don't think we'd be
> foreclosing any opportunities that anyone actually wants to take advantage
> of.  It's quite likely that there is already bit-rot in trying to build or
> use any Linux configuration without nptl.  Does anybody see a problem with
> the idea of making nptl unavoidable on Linux configurations?

I think the change is a good idea.  But for all such changes:

* Checking for identical disassembly of installed libraries is important 
(though there may well be cases with paths in assertions and similar that 
mean you can't get identical disassembly).  It's easy for such a move to 
cause nonobvious changes to the order in which files appear in sysdeps 
directories.  (Thus, if preparing a move for an architecture you can't 
conveniently test yourself, you may wish to provide a git branch and 
request testing.)

* There are lots of nonobvious #includes that depend on exact paths, such 
as:

./nptl/sysdeps/unix/sysv/linux/x86_64/pt-vfork.S:#include <../../../../../../sysdeps/unix/sysv/linux/x86_64/vfork.S>

and:

./sysdeps/aarch64/nptl/pthread_spin_lock.c:#include <sysdeps/../nptl/pthread_spin_lock.c>

So, you need to check #include paths carefully in all moved files, *and* 
check for #includes in other files that might include a file that's moved 
but depend on the exact path to that file.

Once you no longer have the separate sysdeps tree in nptl, I think 
anything needing a particular sysdeps file can just include 
<sysdeps/whatever> without needing any "../" to force the file to be found 
from a particular sysdeps tree.

> 1. Move sysdeps/unix/sysv/linux/CPU/nptl/* -> sysdeps/unix/sysv/linux/CPU/*
>    This should not make any difference to what gets built.  I don't think
>    there are any existing files that would be displaced, but I haven't
>    checked yet.  (Of course Makefile is an exception, but those would get
>    merged straightforwardly so no actual content is displaced.)

There are plenty of cases where linux/CPU/nptl/vfork.S does some #defines 
then includes linux/CPU/vfork.S, for example.

-- 
Joseph S. Myers
joseph@codesourcery.com