This is the mail archive of the
mailing list for the glibc project.
Re: make nptl no longer an add-on?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Thu, 8 May 2014 21:23:44 +0000
- Subject: Re: make nptl no longer an add-on?
- Authentication-results: sourceware.org; auth=none
- References: <20140508193058 dot 722792C3992 at topped-with-meat 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
* There are lots of nonobvious #includes that depend on exact paths, such
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