This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add missing header wrappers under include/
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