This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Assume that pipe2 is always available



On 17/04/2017 15:43, Florian Weimer wrote:
> On 04/17/2017 08:17 PM, Adhemerval Zanella wrote:
>>
>>
>> On 13/04/2017 14:54, Florian Weimer wrote:
>>> On 04/13/2017 07:39 PM, Adhemerval Zanella wrote:
>>>> On 13/04/2017 12:37, Florian Weimer wrote:
>>>>> The Debian patches (which are already required to build glibc before
>>>>> this commit) contain an implementation of pipe2.
>>>>
>>>> I did not follow, which 'Debian patches' are you referring here?
>>>
>>> Upstream master contains an incomplete implementation of O_CLOEXEC support for Hurd.  For example, the file sysdeps/mach/hurd/accept4.c refers to the sock_to_o_flags identifier, but neither glibc, gnumach, nor hurd contain a definition.  The definition is found in a patch in the Debian package.  There is another patch which contains an implementation of pipe2:
>>>
>>> https://sources.debian.net/src/glibc/2.24-8/debian/patches/hurd-i386/tg-pipe2.diff/
>>>
>>> Anyone who wants to build glibc for Hurd needs those Debian patches, so I see no problem with applying this cleanup to upstream master.
>>>
>>> (From the Hurd perspective.  NaCl does not support pipe2, either.)
>>
>> Right, I think we need to sync on master since it seems required to actually
>> build hurd.
> 
> Would you please clarify what you mean?  Do you suggest we have to pull in the Debian patches before we should apply this pipe2 cleanup?

I think we can push pipe2 cleanup first and then if you have time sync hurd
patches with debian. It would be good to have some hurd developer to ack
about these patches as well...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]