Re: [PATCH] Add missing header wrappers under include/

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 11 Feb 2019, Florian Weimer wrote:

> Are missing wrapper headers something we should test for in a generic
> fashion at all?

There are at least three separate potential problems (where people can 
make a mistake that doesn't immediately produce an obvious build or test 
failure) relating to the current handling of installed headers:

(a) Missing wrappers meaning code can quietly end up using an installed 
header instead of one from the build tree.

(b) Attempted sysdeps overrides in the presence of such wrappers that do 
not actually work properly (the issue with overridden bits/ headers 
needing to go in top-level bits/ rather than in some other directory with 
a wrapper, though of course this applies to anything with a wrapper 
including a particular path to an overridden file).

(c) Failing to add a new header (that's included from an installed header) 
to the relevant Makefile, so it doesn't get installed and builds (possibly 
only under certain conditions) with installed headers fail, though 
everything works fine when building and testing glibc.

I think requiring and testing for wrapper headers is a reasonable way to 
address (a) - if you test for such headers in all cases, you avoid the 
fragility of the present approach where a wrapper is only needed when a 
header is used outside the directory that contains it.

It would also be worth thinking separately about how to implement tests to 
avoid issues (b) and (c).  For example, now that testing installs glibc 
into a container, that container directory could be used to examine the 
full set of installed headers together to see if they have any #includes 
of headers not present there (other than kernel headers, other-ABI 
gnu/stubs-*.h and gnu/lib-names-*.h, etc.).  (This is awkward to test for 
on a per-directory basis because one installed header can include a header 
that itself is installed by another directory.)

scripts/check-local-headers.sh attempts to test for something related to 
(a).  However, issues with it include (i) it runs before the rest of the 
testsuite (it would be a more thorough test if it ran after the rest of 
the testsuite so it checked for problem uses of installed headers in 
testcases; it ought to be possible to fix the ordering so it does run 
after the other tests again); and (ii) of course it only detects issues 
that show up with the current glibc configuration, whereas your proposed 
check that every installed header has a wrapper would mean more 
system-specific issues get detected in a single glibc testsuite run rather 
than only in a build-many-glibcs.py run.

-- 
Joseph S. Myers
joseph@codesourcery.com