[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

On 3/20/2016 11:26 AM, Corinna Vinschen wrote:
> On Mar 19 14:03, Ken Brown wrote:
>> On 3/19/2016 8:34 AM, Ken Brown wrote:
>>> On 3/19/2016 6:32 AM, Corinna Vinschen wrote:
>>>> On Mar 18 22:24, Ken Brown wrote:
>>>>> On 3/18/2016 7:29 PM, Yaakov Selkowitz wrote:
>>>>>> On 2016-03-18 18:05, Yaakov Selkowitz wrote:
>>>>>>> On 2016-03-18 17:25, Ken Brown wrote:
>>>>>>>> The problem I reported in
>>>>>>>> https://www.cygwin.com/ml/cygwin/2015-12/msg00183.html has
>>>>>>>> reappeared.
>>>>>>>> It looks like your fix
>>>>>>>> (https://www.cygwin.com/ml/cygwin/2015-12/msg00199.html) got
>>>>>>>> reverted.
>>>>>>>
>>>>>>> The commit message for removing the include did not indicate what
>>>>>>> prompted it.  However, the include is necessary for BSD compatibility,
>>>>>>> and other software fails to build without it.
>>>>>>>
>>>>>>> I would look into emacs and see what feature test macro(s) they enable
>>>>>>> on *Linux*, and use the same for Cygwin.
>>>>>>
>>>>>> Might this be it?
>>>>>>
>>>>>> http://git.savannah.gnu.org/cgit/emacs.git/tree/lib/sys_select.in.h
>>>>>
>>>>> This file is part of the Gnulib module that I mentioned in the thread I
>>>>> cited above.
>>>>>
>>>>>> There's some seriously hackish things going on in that file, some of
>>>>>> them Cygwin specific.
>>>>>
>>>>> I think such things are often necessary in Gnulib, but I'll leave it
>>>>> to Eric
>>>>> to comment further.  In any case, Eric said in our original
>>>>> discussion that
>>>>> there might be a Gnulib fix for this problem, but then he and Corinna
>>>>> ended
>>>>> up deciding it was better to remove the include.
>>>>
>>>> Glibc uses __USE_MISC to guard the inclusion of sys/select.h, newlib's
>>>> header uses __BSD_VISIBLE which is almost the same.  But we have the
>>>> equivalent __MISC_VISIBLE as well.  Do you want to change that, Yaakov?
>>>>
>>>> The discussion with Eric was about the POSIX-ness and at the time it
>>>> seemed like the simplest solution to remove the include.  But Yaakov
>>>> is right.  If it's the right thing to do for Glibc to include it
>>>> with careful guarding, it should be the right thing for us as well.
>>>
>>> So I think that means we're back to looking for a Gnulib solution. Eric,
>>> can you follow up on that?
>>
>> Never mind.  I just sent a report to bug-gnulib, so you can follow up there.
>
> Pointer?

http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00054.html

Please check what I wrote in response to Paul and correct any mistakes I 
might have made.

Thanks.

Ken