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

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

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

[Joseph Myers]

On Mon, 22 Aug 2016, Zack Weinberg wrote:

> 2) What might depend on that mode *not* being like compilation against
> the installed library?

If it's used for tests, various tests use internal headers (although they 
still shouldn't mostly depend on _LIBC conditionals, include/ wrappers 
etc.).

> 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.

conform/ (a) doesn't use any of the standard compilation rules, just 
$(CC), which avoids getting _LIBC defined, and (b) defines _ISOMAC, which 
the include/ wrappers are supposed to take to mean only to serve as 
wrappers for the installed header (needed, because many of the installed 
headers are in subdirectories not searched when building in other 
subdirectories) and not to include any internal declarations.

A few individual tests outside conform/ define _ISOMAC and undefine _LIBC 
and _GNU_SOURCE to test other standards modes.  But as a consequence those 
tests are unable to use test-skeleton.c (we ought to move to most of 
test-skeleton being a separately built object, not #included and depending 
on macros defined by the including file, so it can be used by such tests).

It would be good to move internal declarations out of the include/ 
wrappers and into separate headers with different names, but if you do 
that with the libc_hidden_proto and __* declarations corresponding to 
public functions, that's an awful lot of files in glibc that need to 
include extra headers.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Zack Weinberg]

On Mon, Aug 22, 2016 at 5:58 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 22 Aug 2016, Zack Weinberg wrote:
>> 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.
>
> conform/ (a) doesn't use any of the standard compilation rules, just
> $(CC), which avoids getting _LIBC defined, and (b) defines _ISOMAC, which
> the include/ wrappers are supposed to take to mean only to serve as
> wrappers for the installed header (needed, because many of the installed
> headers are in subdirectories not searched when building in other
> subdirectories) and not to include any internal declarations.

Thanks, that was exactly the hint I needed.  Patches coming up :)

zw