This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [hurd,commited] hurd: do not check Mach and Hurd headers
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