* [hurd,commited] hurd: do not check Mach and Hurd headers
@ 2018-03-03 19:18 Samuel Thibault
2018-03-03 22:08 ` Joseph Myers
0 siblings, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-03 19:18 UTC (permalink / raw)
To: libc-alpha; +Cc: Samuel Thibault
as they are not standard.
* scripts/check-installed-headers.sh: Ignore Hurd and Mach headers.
---
ChangeLog | 4 ++++
| 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index 775e4c6ab3..dd65beebc6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-03-03 Samuel Thibault <samuel.thibault@ens-lyon.org>
+
+ * scripts/check-installed-headers.sh: Ignore Hurd and Mach headers.
+
2018-03-03 Andreas Schwab <schwab@linux-m68k.org>
[BZ #22918]
--git a/scripts/check-installed-headers.sh b/scripts/check-installed-headers.sh
index 7ffd2b8e74..f7f55917f7 100644
--- a/scripts/check-installed-headers.sh
+++ b/scripts/check-installed-headers.sh
@@ -126,6 +126,13 @@ EOF
fi
;;
esac
+ ;;
+
+ # Hurd and Mach headers are not standard anyway
+ (hurd.h | hurd/*.h | faultexc_server.h | \
+ mach.h | mach_init.h | mach_error.h | mach-shortcuts.h | mach/* | \
+ device/* | lock-intern.h | spin-lock.h | machine-sp.h)
+ continue;;
esac
echo :: "$header"
--
2.16.1
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-03 19:18 [hurd,commited] hurd: do not check Mach and Hurd headers Samuel Thibault
@ 2018-03-03 22:08 ` Joseph Myers
2018-03-03 22:32 ` Samuel Thibault
0 siblings, 1 reply; 17+ messages in thread
From: Joseph Myers @ 2018-03-03 22:08 UTC (permalink / raw)
To: Samuel Thibault; +Cc: libc-alpha
On Sat, 3 Mar 2018, Samuel Thibault wrote:
> as they are not standard.
That's not a sufficient reason for this change. What this script is
checking is nothing to do with whether the headers are standard; it's that
each header can be included in isolation with any supported feature test
macro defined (actually, just a few macros are tested) and in any C/C++
standards mode.
That property should apply to Hurd-specific headers installed by glibc
just as it applies to non-Hurd-specific headers (this script doesn't test
headers not installed by glibc). That is, any case of such a header
failing this test is presumptively a bug that should be fixed. (If a
header is in fact purely internal, not for direct use by users or by other
installed headers, stopping it being installed is the correct fix - this
test is specifically for installed headers. If a header is installed only
for use by other installed headers and is not meant to be included
directly by user programs, it should move into bits/; bits/ headers are
already excluded from this test.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-03 22:08 ` Joseph Myers
@ 2018-03-03 22:32 ` Samuel Thibault
2018-03-03 22:53 ` Joseph Myers
0 siblings, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-03 22:32 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Hello,
Joseph Myers, on sam. 03 mars 2018 22:08:49 +0000, wrote:
> On Sat, 3 Mar 2018, Samuel Thibault wrote:
>
> > as they are not standard.
>
> That's not a sufficient reason for this change. What this script is
> checking is nothing to do with whether the headers are standard; it's that
> each header can be included in isolation with any supported feature test
> macro defined (actually, just a few macros are tested) and in any C/C++
> standards mode.
Well hurd & mach headers are not meant to be used without _GNU_SOURCE=1,
for a start... Usual applications wouldn't use them anyway, only things
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.
Samuel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-03 22:32 ` Samuel Thibault
@ 2018-03-03 22:53 ` Joseph Myers
2018-03-03 23:57 ` Samuel Thibault
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Joseph Myers @ 2018-03-03 22:53 UTC (permalink / raw)
To: Samuel Thibault; +Cc: libc-alpha
On Sat, 3 Mar 2018, Samuel Thibault wrote:
> Well hurd & mach headers are not meant to be used without _GNU_SOURCE=1,
> for a start... Usual applications wouldn't use them anyway, only things
If a header requires some type T, I'd expect it to include bits/types/T.h,
thereby ensuring that type T is defined regardless of feature test macros,
instead of including some other header that might or might not define type
T depending on feature test macros.
Likewise for any other dependencies on features from other headers. (And
of course these headers shouldn't themselves contain feature test macro
conditionals.)
> 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. 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.
I think it's dubious to have a #error requiring _GNU_SOURCE to be used,
because it should always be possible to write a header in a way that
doesn't have such a requirement. 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.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-03 22:53 ` Joseph Myers
@ 2018-03-03 23:57 ` Samuel Thibault
2018-03-04 1:33 ` Joseph Myers
2018-03-04 0:32 ` Samuel Thibault
2018-03-04 2:55 ` Samuel Thibault
2 siblings, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-03 23:57 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-03 22:53 ` Joseph Myers
2018-03-03 23:57 ` Samuel Thibault
@ 2018-03-04 0:32 ` Samuel Thibault
2018-03-04 1:28 ` Joseph Myers
2018-03-04 2:55 ` Samuel Thibault
2 siblings, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-04 0:32 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Joseph Myers, on sam. 03 mars 2018 22:53:23 +0000, wrote:
> I think it's dubious to have a #error requiring _GNU_SOURCE to be used,
> because it should always be possible to write a header in a way that
> doesn't have such a requirement. But in any case where, after analysis,
> such a #error is found to make sense
Notably, most Hurd interfaces use the error_t type, which is GNU-only.
I assume this is enough to make it a #error case?
Samuel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 0:32 ` Samuel Thibault
@ 2018-03-04 1:28 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2018-03-04 1:28 UTC (permalink / raw)
To: Samuel Thibault; +Cc: libc-alpha
On Sun, 4 Mar 2018, Samuel Thibault wrote:
> Joseph Myers, on sam. 03 mars 2018 22:53:23 +0000, wrote:
> > I think it's dubious to have a #error requiring _GNU_SOURCE to be used,
> > because it should always be possible to write a header in a way that
> > doesn't have such a requirement. But in any case where, after analysis,
> > such a #error is found to make sense
>
> Notably, most Hurd interfaces use the error_t type, which is GNU-only.
> I assume this is enough to make it a #error case?
No. Create bits/types/error_t.h (which would have a generic version and a
Hurd version), which would define error_t (subject to __error_t_defined as
a multiple-include guard). Then make errno.h include
<bits/types/error_t.h> if __USE_GNU, while all the Hurd headers using that
type would include <bits/types/error_t.h> unconditionally.
(sysdeps/mach/hurd/bits/errno.h would no longer need to define error_t and
wouldn't need to include <bits/types/error_t.h> either because of errno.h
doing so - I'm assuming the current reason for defining error_t there is
simply to get a Hurd-specific definition instead of the default from
errno.h, which would be dealt with by having a Hurd-specific
bits/types/error_t.h.)
Having such a bits/types/*.h header is the normal way in glibc of dealing
with types that different headers need under different conditions.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-03 23:57 ` Samuel Thibault
@ 2018-03-04 1:33 ` Joseph Myers
2018-03-04 1:35 ` Samuel Thibault
0 siblings, 1 reply; 17+ messages in thread
From: Joseph Myers @ 2018-03-04 1:33 UTC (permalink / raw)
To: Samuel Thibault; +Cc: libc-alpha
On Sun, 4 Mar 2018, Samuel Thibault wrote:
> > 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?
It's not yet clear any such special cases in the script are needed. But
if they are, they would only be for specific headers that use #error
without __USE_GNU, not any wildcard such as hurd/*.h, and we should review
whether the #error usage is necessary or whether there's a better approach
in each particular case.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 1:33 ` Joseph Myers
@ 2018-03-04 1:35 ` Samuel Thibault
2018-03-04 1:41 ` Joseph Myers
0 siblings, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-04 1:35 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Joseph Myers, on dim. 04 mars 2018 01:33:18 +0000, wrote:
> On Sun, 4 Mar 2018, Samuel Thibault wrote:
> > > 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?
>
> It's not yet clear any such special cases in the script are needed.
See the patch: mach/mach/mig_support.h explains why it needs
_GNU_SOURCE.
> But
> if they are, they would only be for specific headers that use #error
> without __USE_GNU, not any wildcard such as hurd/*.h,
Sure, I _*NEVER*_ meant to do anything like that, as my patch shows.
Samuel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 1:35 ` Samuel Thibault
@ 2018-03-04 1:41 ` Joseph Myers
2018-03-04 1:43 ` Samuel Thibault
2018-03-04 1:46 ` Samuel Thibault
0 siblings, 2 replies; 17+ messages in thread
From: Joseph Myers @ 2018-03-04 1:41 UTC (permalink / raw)
To: Samuel Thibault; +Cc: libc-alpha
On Sun, 4 Mar 2018, Samuel Thibault wrote:
> Joseph Myers, on dim. 04 mars 2018 01:33:18 +0000, wrote:
> > On Sun, 4 Mar 2018, Samuel Thibault wrote:
> > > > 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?
> >
> > It's not yet clear any such special cases in the script are needed.
>
> See the patch: mach/mach/mig_support.h explains why it needs
> _GNU_SOURCE.
Well, I disagree with the explanation there. The use of __stpncpy is in
an _LIBC-conditional block, and _LIBC can reasonably be taken to imply
_GNU_SOURCE, so if you remove the #error I see no reason for this header
to break without _GNU_SOURCE. It just requires a few Mach-specific types,
and all the headers declaring such types should do so unconditionally.
(Such _LIBC-conditional code should where possible move out of installed
headers and into non-installed headers used only for building glibc, but
that's a separate longstanding issue. _LIBC conditionals are more
appropriate for e.g. code shared with gnulib.)
> > But
> > if they are, they would only be for specific headers that use #error
> > without __USE_GNU, not any wildcard such as hurd/*.h,
>
> Sure, I _*NEVER*_ meant to do anything like that, as my patch shows.
My reading of <https://sourceware.org/ml/libc-alpha/2018-03/msg00074.html>
is that it still has:
+ # Hurd headers are not standard anyway
+ (hurd.h | hurd/*.h | faultexc_server.h)
+ continue;;
and as noted, I don't think hurd/*.h should be special-cased like that (or
that "not standard" is a sufficient explanation for a comment here).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 1:41 ` Joseph Myers
@ 2018-03-04 1:43 ` Samuel Thibault
2018-03-04 1:46 ` Joseph Myers
2018-03-04 1:46 ` Samuel Thibault
1 sibling, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-04 1:43 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Joseph Myers, on dim. 04 mars 2018 01:41:43 +0000, wrote:
> My reading of <https://sourceware.org/ml/libc-alpha/2018-03/msg00074.html>
> is that it still has:
>
> + # Hurd headers are not standard anyway
> + (hurd.h | hurd/*.h | faultexc_server.h)
> + continue;;
The reading of the patch really is all the - on mach headers. Small
step to get something done instead of having to do _*ALL*_ the work at
one time and never manage to find motivation to finish it all.
> and as noted, I don't think hurd/*.h should be special-cased like that (or
> that "not standard" is a sufficient explanation for a comment here).
Sure, that was never the intent of that patch.
Samuel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 1:43 ` Samuel Thibault
@ 2018-03-04 1:46 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2018-03-04 1:46 UTC (permalink / raw)
To: Samuel Thibault; +Cc: libc-alpha
On Sun, 4 Mar 2018, Samuel Thibault wrote:
> Joseph Myers, on dim. 04 mars 2018 01:41:43 +0000, wrote:
> > My reading of <https://sourceware.org/ml/libc-alpha/2018-03/msg00074.html>
> > is that it still has:
> >
> > + # Hurd headers are not standard anyway
> > + (hurd.h | hurd/*.h | faultexc_server.h)
> > + continue;;
>
> The reading of the patch really is all the - on mach headers. Small
> step to get something done instead of having to do _*ALL*_ the work at
> one time and never manage to find motivation to finish it all.
I don't actually see the problem with having some of these tests failing -
no Hurd special cases in this script - unless and until we decide that a
particular Hurd special case in this script is appropriate. That was how
we handled many architecture-specific fixes for header problems shown by
these tests for GNU/Linux (some of these tests failed on some
architectures for some time); I think it's how we should handle them for
Hurd. When individual headers are fixed, the number of failures may go
down.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 1:41 ` Joseph Myers
2018-03-04 1:43 ` Samuel Thibault
@ 2018-03-04 1:46 ` Samuel Thibault
1 sibling, 0 replies; 17+ messages in thread
From: Samuel Thibault @ 2018-03-04 1:46 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Joseph Myers, on dim. 04 mars 2018 01:41:43 +0000, wrote:
> Well, I disagree with the explanation there. The use of __stpncpy is in
> an _LIBC-conditional block,
Indeed, that got in in between.
/me more and more tired of fixed all kinds of code that were written by
other people more than two decades ago.
Samuel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-03 22:53 ` Joseph Myers
2018-03-03 23:57 ` Samuel Thibault
2018-03-04 0:32 ` Samuel Thibault
@ 2018-03-04 2:55 ` Samuel Thibault
2018-03-04 16:08 ` Zack Weinberg
2 siblings, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-04 2:55 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
Joseph Myers, on sam. 03 mars 2018 22:53:23 +0000, wrote:
> it should always be possible to write a header in a way that
> doesn't have such a requirement.
I'm almost there, the only remaining issue is that hurd/hurd/signal.h
uses struct sigaction. I guess I should move existing definitions to a
struct_sigaction.h header?
Samuel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 2:55 ` Samuel Thibault
@ 2018-03-04 16:08 ` Zack Weinberg
2018-03-04 18:10 ` Samuel Thibault
0 siblings, 1 reply; 17+ messages in thread
From: Zack Weinberg @ 2018-03-04 16:08 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Joseph Myers, GNU C Library
On Sat, Mar 3, 2018 at 9:55 PM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
> Joseph Myers, on sam. 03 mars 2018 22:53:23 +0000, wrote:
>> it should always be possible to write a header in a way that
>> doesn't have such a requirement.
>
> I'm almost there, the only remaining issue is that hurd/hurd/signal.h
> uses struct sigaction. I guess I should move existing definitions to a
> struct_sigaction.h header?
In this case, you just need a Hurd version of the existing
bits/sigaction.h. (It's bits/sigaction.h rather than
bits/types/struct_sigaction.h because it also defines the SA_*
constants.)
zw
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 16:08 ` Zack Weinberg
@ 2018-03-04 18:10 ` Samuel Thibault
2018-03-05 0:30 ` Zack Weinberg
0 siblings, 1 reply; 17+ messages in thread
From: Samuel Thibault @ 2018-03-04 18:10 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Joseph Myers, GNU C Library
Zack Weinberg, on dim. 04 mars 2018 11:08:00 -0500, wrote:
> On Sat, Mar 3, 2018 at 9:55 PM, Samuel Thibault
> <samuel.thibault@ens-lyon.org> wrote:
> > Joseph Myers, on sam. 03 mars 2018 22:53:23 +0000, wrote:
> >> it should always be possible to write a header in a way that
> >> doesn't have such a requirement.
> >
> > I'm almost there, the only remaining issue is that hurd/hurd/signal.h
> > uses struct sigaction. I guess I should move existing definitions to a
> > struct_sigaction.h header?
>
> In this case, you just need a Hurd version of the existing
> bits/sigaction.h.
I don't understand why a different version. Can't I just make
hurd/hurd/signal.h include <bits/sigaction.h>? (well, there is a
technical reason: it does not have multi-inclusion guard, but that can
be fixed)
Samuel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [hurd,commited] hurd: do not check Mach and Hurd headers
2018-03-04 18:10 ` Samuel Thibault
@ 2018-03-05 0:30 ` Zack Weinberg
0 siblings, 0 replies; 17+ messages in thread
From: Zack Weinberg @ 2018-03-05 0:30 UTC (permalink / raw)
To: Samuel Thibault; +Cc: Joseph Myers, GNU C Library
On Sun, Mar 4, 2018 at 1:09 PM, Samuel Thibault
<samuel.thibault@ens-lyon.org> wrote:
> Zack Weinberg, on dim. 04 mars 2018 11:08:00 -0500, wrote:
>> On Sat, Mar 3, 2018 at 9:55 PM, Samuel Thibault
>> <samuel.thibault@ens-lyon.org> wrote:
>> > Joseph Myers, on sam. 03 mars 2018 22:53:23 +0000, wrote:
>> >> it should always be possible to write a header in a way that
>> >> doesn't have such a requirement.
>> >
>> > I'm almost there, the only remaining issue is that hurd/hurd/signal.h
>> > uses struct sigaction. I guess I should move existing definitions to a
>> > struct_sigaction.h header?
>>
>> In this case, you just need a Hurd version of the existing
>> bits/sigaction.h.
>
> I don't understand why a different version. Can't I just make
> hurd/hurd/signal.h include <bits/sigaction.h>? (well, there is a
> technical reason: it does not have multi-inclusion guard, but that can
> be fixed)
Oh, yes, if the existing generic bits/sigaction.h works for Hurd then
that's fine. I thought there had to be something wrong with it,
because hurd/signal.h already includes signal.h which includes
bits/sigaction.h ... but now I realize that the problem is signal.h
doesn't _always_ include bits/sigaction.h.
zw
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-03-05 0:30 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-03 19:18 [hurd,commited] hurd: do not check Mach and Hurd headers Samuel Thibault
2018-03-03 22:08 ` Joseph Myers
2018-03-03 22:32 ` Samuel Thibault
2018-03-03 22:53 ` Joseph Myers
2018-03-03 23:57 ` Samuel Thibault
2018-03-04 1:33 ` Joseph Myers
2018-03-04 1:35 ` Samuel Thibault
2018-03-04 1:41 ` Joseph Myers
2018-03-04 1:43 ` Samuel Thibault
2018-03-04 1:46 ` Joseph Myers
2018-03-04 1:46 ` Samuel Thibault
2018-03-04 0:32 ` Samuel Thibault
2018-03-04 1:28 ` Joseph Myers
2018-03-04 2:55 ` Samuel Thibault
2018-03-04 16:08 ` Zack Weinberg
2018-03-04 18:10 ` Samuel Thibault
2018-03-05 0:30 ` Zack Weinberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).