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

[Joseph Myers <joseph at codesourcery dot com>]

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