Internal wrappers and _LIBC .vs. tests _of_ the headers as installed

[Zack Weinberg]

I've been working on a set of patches that attempt to ensure that
every installed header is usable in isolation (not needing anything
else to be included first) in both C and C++ and in a variety of
feature-selection modes. As the final act of this patchset I would
like to add a test that makes sure everything _stays_ that way. I've
run into a problem, though. It was my understanding that
MODULE_NAME=nonlib mode was *supposed* to match exactly, or "as
exactly as practical", with what you get if you compile against the
installed headers, but this does not seem to be the case.
libc-symbols.h defines _LIBC (and _GNU_SOURCE) unconditionally, and
the Makefiles add include/ and sysdeps/.../include/ to the search
paths unconditionally. These in turn bring in code (libc-lockP.h, for
instance) that is not intended to ever be used outside the core
library, and hilarity ensues, especially if you're using the C++
compiler. (I don't understand how C++ tests have ever worked.)

Questions are:

1) What is MODULE_NAME=nonlib mode *supposed* to be like?
2) What might depend on that mode *not* being like compilation against
the installed library?
3) What do you think is the most practical way to kludge together a
test mode that *does* match the behavior of the installed headers?
3a) How exactly does conform/ deal with this?  I tried to read that
code and came up with "it doesn't", which must be wrong.

zw