Re: [hurd,commited] hurd: do not check Mach and Hurd headers

[Samuel Thibault <samuel dot thibault at ens-lyon dot org>]

Hello,

Joseph Myers, on sam. 03 mars 2018 22:53:23 +0000, wrote:
> On Sat, 3 Mar 2018, Samuel Thibault wrote:
> > like e.g. libparted, Xorg, etc. which need to interact closely with
> > system things use them, and thus have to enable the GNU extensions.  You
> > can think of them like linux/ headers.
> 
> Well, all linux/*.h and asm/*h headers also ought to be includable in 
> isolation, with any feature test macros defined.  But that's the Linux 
> kernel's problem, not ours, since it's the Linux kernel that provides 
> those headers.  Whereas this test is purely for headers installed by 
> glibc.

I only mentioned Linux to point out which kind of interface we are
talking about: not something for normal applications.  Here, glibc is
distributing pieces of the Hurd which the Linux kernel distributes.

> And every header installed by glibc should either work in 
> isolation, or if it's not meant to work in some context should have a 
> #error explaining the issue - like the #errors in bits/*.h headers saying 
> not to include them directly, or the #error in sys/elf.h for x86_64 
> GNU/Linux, for example.

Ok.

> But in any case where, after analysis, such a #error is found to
> make sense (and a comment goes on the #error explaining why it
> makes sense), that specific header might have testing disabled in
> check-installed-headers.sh *only* when _GNU_SOURCE is not passed - not
> for other feature test macros, not using wildcards like hurd/*.h.

I have sent a patch adding support for this, and whitelisting mach
headers, could you have a look?

Samuel