Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]


[CCed cygwin-apps to reach out to all package maintainers]

On Mar 18 16:58, Ken Brown wrote:
> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
> >I released a new Cygwin TEST version 2.5.0-0.8.
> >
> >If things are not going very wrong, this is basically what you'll
> >get as 2.5.0-1 release.  Please, please test and report regressions.
> 
> Does this release include Yaakov's overhaul of the feature test macros?

Sorry, I completely forgot to metion this in my release mail, which
is especially weird because I created this test release to allow testing
the new feature test macros in the first place.  Sorry!

> If
> so, it might be a good idea for maintainers to test that nothing unexpected
> happens when they build their packages.

Yes, that's really a good idea.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>
> [CCed cygwin-apps to reach out to all package maintainers]
>
> On Mar 18 16:58, Ken Brown wrote:
>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>
>>> If things are not going very wrong, this is basically what you'll
>>> get as 2.5.0-1 release.  Please, please test and report regressions.
>>
>> Does this release include Yaakov's overhaul of the feature test macros?
>
> Sorry, I completely forgot to metion this in my release mail, which
> is especially weird because I created this test release to allow testing
> the new feature test macros in the first place.  Sorry!

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.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

On 3/18/2016 6:25 PM, Ken Brown wrote:
> On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>>
>> [CCed cygwin-apps to reach out to all package maintainers]
>>
>> On Mar 18 16:58, Ken Brown wrote:
>>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>>
>>>> If things are not going very wrong, this is basically what you'll
>>>> get as 2.5.0-1 release.  Please, please test and report regressions.
>>>
>>> Does this release include Yaakov's overhaul of the feature test macros?
>>
>> Sorry, I completely forgot to metion this in my release mail, which
>> is especially weird because I created this test release to allow testing
>> the new feature test macros in the first place.  Sorry!
>
> 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.

Yes, that happened in git commit ee97c4b.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Yaakov Selkowitz]

On 2016-03-18 17:25, Ken Brown wrote:
> On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>> On Mar 18 16:58, Ken Brown wrote:
>>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>>
>>>> If things are not going very wrong, this is basically what you'll
>>>> get as 2.5.0-1 release.  Please, please test and report regressions.
>>>
>>> Does this release include Yaakov's overhaul of the feature test macros?
>>
>> Sorry, I completely forgot to metion this in my release mail, which
>> is especially weird because I created this test release to allow testing
>> the new feature test macros in the first place.  Sorry!
>
> 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.

-- 
Yaakov

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Yaakov Selkowitz]

On 2016-03-18 18:05, Yaakov Selkowitz wrote:
> On 2016-03-18 17:25, Ken Brown wrote:
>> On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>>> On Mar 18 16:58, Ken Brown wrote:
>>>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>>>
>>>>> If things are not going very wrong, this is basically what you'll
>>>>> get as 2.5.0-1 release.  Please, please test and report regressions.
>>>>
>>>> Does this release include Yaakov's overhaul of the feature test macros?
>>>
>>> Sorry, I completely forgot to metion this in my release mail, which
>>> is especially weird because I created this test release to allow testing
>>> the new feature test macros in the first place.  Sorry!
>>
>> 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

There's some seriously hackish things going on in that file, some of 
them Cygwin specific.  As far as this is concerned, our headers should 
be no different than glibc.

BTW, folks, I'm here to help deal with any fallout from these changes, 
but this is going to be the first answer to such issues: others need to 
stop making hackish, wrong, or outdated assumptions about Cygwin.  Yes, 
that means pushing some patches to undo this mistreatment, but nothing 
new there.  As of today's 2.5.0-0.8, it should only considered a bug in 
our headers when something does not compile if and only if Cygwin is 
treated identically to glibc.

-- 
Yaakov

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

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:
>>> On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>>>> On Mar 18 16:58, Ken Brown wrote:
>>>>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>>>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>>>>
>>>>>> If things are not going very wrong, this is basically what you'll
>>>>>> get as 2.5.0-1 release.  Please, please test and report regressions.
>>>>>
>>>>> Does this release include Yaakov's overhaul of the feature test
>>>>> macros?
>>>>
>>>> Sorry, I completely forgot to metion this in my release mail, which
>>>> is especially weird because I created this test release to allow
>>>> testing
>>>> the new feature test macros in the first place.  Sorry!
>>>
>>> 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.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

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:
> >>>On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
> >>>>On Mar 18 16:58, Ken Brown wrote:
> >>>>>On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
> >>>>>>I released a new Cygwin TEST version 2.5.0-0.8.
> >>>>>>
> >>>>>>If things are not going very wrong, this is basically what you'll
> >>>>>>get as 2.5.0-1 release.  Please, please test and report regressions.
> >>>>>
> >>>>>Does this release include Yaakov's overhaul of the feature test
> >>>>>macros?
> >>>>
> >>>>Sorry, I completely forgot to metion this in my release mail, which
> >>>>is especially weird because I created this test release to allow
> >>>>testing
> >>>>the new feature test macros in the first place.  Sorry!
> >>>
> >>>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.

I guess we won't get off without toothing aches :}


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

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:
>>>>> On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>>>>>> On Mar 18 16:58, Ken Brown wrote:
>>>>>>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>>>>>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>>>>>>
>>>>>>>> If things are not going very wrong, this is basically what you'll
>>>>>>>> get as 2.5.0-1 release.  Please, please test and report regressions.
>>>>>>>
>>>>>>> Does this release include Yaakov's overhaul of the feature test
>>>>>>> macros?
>>>>>>
>>>>>> Sorry, I completely forgot to metion this in my release mail, which
>>>>>> is especially weird because I created this test release to allow
>>>>>> testing
>>>>>> the new feature test macros in the first place.  Sorry!
>>>>>
>>>>> 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?

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

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:
>>>>>> On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
>>>>>>> On Mar 18 16:58, Ken Brown wrote:
>>>>>>>> On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
>>>>>>>>> I released a new Cygwin TEST version 2.5.0-0.8.
>>>>>>>>>
>>>>>>>>> If things are not going very wrong, this is basically what you'll
>>>>>>>>> get as 2.5.0-1 release.  Please, please test and report
>>>>>>>>> regressions.
>>>>>>>>
>>>>>>>> Does this release include Yaakov's overhaul of the feature test
>>>>>>>> macros?
>>>>>>>
>>>>>>> Sorry, I completely forgot to metion this in my release mail, which
>>>>>>> is especially weird because I created this test release to allow
>>>>>>> testing
>>>>>>> the new feature test macros in the first place.  Sorry!
>>>>>>
>>>>>> 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.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

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?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [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

Re: [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

Re: [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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Yaakov Selkowitz]

On 2016-03-20 12:29, Ken Brown wrote:
>>> Never mind.  I just sent a report to bug-gnulib, so you can follow up
>>> there.
>
> 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.

Treating Cygwin just like glibc should generally be the solution.

-- 
Yaakov

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
> On 2016-03-20 12:29, Ken Brown wrote:
>>>> Never mind.  I just sent a report to bug-gnulib, so you can follow up
>>>> there.
>>
>> 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.
>
> Treating Cygwin just like glibc should generally be the solution.

The problem is now fixed in upstream Gnulib.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

Hi Ken,

On Mar 21 08:05, Ken Brown wrote:
> On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
> >On 2016-03-20 12:29, Ken Brown wrote:
> >>>>Never mind.  I just sent a report to bug-gnulib, so you can follow up
> >>>>there.
> >>
> >>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.
> >
> >Treating Cygwin just like glibc should generally be the solution.
> 
> The problem is now fixed in upstream Gnulib.

I just read the thread and it occured to me that this doesn't only
affect Cygwin, but all systems using newlib starting with the next
version of newlib.

That reminds me that we have to bump newlib's version about now.

Would you mind to follow up with that problem on bug-gnulib?  The test
should probably look like this, more or less:

#!((defined __GLIBC__ \
    || (defined __NEWLIB__ \
    && ((__NEWLIB__ == 2 && __NEWLIB_MINOR__ >= 4) || __NEWLIB__ >= 3))) \
 && !defined __UCLIBC__)

As for the actual version number to test I have to talk to Jeff if we
can change the version to 2.4 or at least 2.3.1.  2.4 would simplify the
test in gnulib, otherwise the test gets a bit more complicated.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

On 3/21/2016 9:06 AM, Corinna Vinschen wrote:
> Hi Ken,
>
> On Mar 21 08:05, Ken Brown wrote:
>> On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
>>> On 2016-03-20 12:29, Ken Brown wrote:
>>>>>> Never mind.  I just sent a report to bug-gnulib, so you can follow up
>>>>>> there.
>>>>
>>>> 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.
>>>
>>> Treating Cygwin just like glibc should generally be the solution.
>>
>> The problem is now fixed in upstream Gnulib.
>
> I just read the thread and it occured to me that this doesn't only
> affect Cygwin, but all systems using newlib starting with the next
> version of newlib.
>
> That reminds me that we have to bump newlib's version about now.
>
> Would you mind to follow up with that problem on bug-gnulib?  The test
> should probably look like this, more or less:
>
> #!((defined __GLIBC__ \
>      || (defined __NEWLIB__ \
>      && ((__NEWLIB__ == 2 && __NEWLIB_MINOR__ >= 4) || __NEWLIB__ >= 3))) \
>   && !defined __UCLIBC__)
>
> As for the actual version number to test I have to talk to Jeff if we
> can change the version to 2.4 or at least 2.3.1.  2.4 would simplify the
> test in gnulib, otherwise the test gets a bit more complicated.

Sure, I'll follow up on bug-gnulib as soon as you settle on the version 
number.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

On Mar 21 10:13, Ken Brown wrote:
> On 3/21/2016 9:06 AM, Corinna Vinschen wrote:
> >Hi Ken,
> >
> >On Mar 21 08:05, Ken Brown wrote:
> >>On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
> >>>On 2016-03-20 12:29, Ken Brown wrote:
> >>>>>>Never mind.  I just sent a report to bug-gnulib, so you can follow up
> >>>>>>there.
> >>>>
> >>>>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.
> >>>
> >>>Treating Cygwin just like glibc should generally be the solution.
> >>
> >>The problem is now fixed in upstream Gnulib.
> >
> >I just read the thread and it occured to me that this doesn't only
> >affect Cygwin, but all systems using newlib starting with the next
> >version of newlib.
> >
> >That reminds me that we have to bump newlib's version about now.
> >
> >Would you mind to follow up with that problem on bug-gnulib?  The test
> >should probably look like this, more or less:
> >
> >#!((defined __GLIBC__ \
> >     || (defined __NEWLIB__ \
> >     && ((__NEWLIB__ == 2 && __NEWLIB_MINOR__ >= 4) || __NEWLIB__ >= 3))) \
> >  && !defined __UCLIBC__)
> >
> >As for the actual version number to test I have to talk to Jeff if we
> >can change the version to 2.4 or at least 2.3.1.  2.4 would simplify the
> >test in gnulib, otherwise the test gets a bit more complicated.
> 
> Sure, I'll follow up on bug-gnulib as soon as you settle on the version
> number.

Thank you.  From the thread I take it the version number isn't that
important anymore?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

On 3/22/2016 5:30 AM, Corinna Vinschen wrote:
> On Mar 21 10:13, Ken Brown wrote:
>> On 3/21/2016 9:06 AM, Corinna Vinschen wrote:
>>> Hi Ken,
>>>
>>> On Mar 21 08:05, Ken Brown wrote:
>>>> On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
>>>>> On 2016-03-20 12:29, Ken Brown wrote:
>>>>>>>> Never mind.  I just sent a report to bug-gnulib, so you can follow up
>>>>>>>> there.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Treating Cygwin just like glibc should generally be the solution.
>>>>
>>>> The problem is now fixed in upstream Gnulib.
>>>
>>> I just read the thread and it occured to me that this doesn't only
>>> affect Cygwin, but all systems using newlib starting with the next
>>> version of newlib.
>>>
>>> That reminds me that we have to bump newlib's version about now.
>>>
>>> Would you mind to follow up with that problem on bug-gnulib?  The test
>>> should probably look like this, more or less:
>>>
>>> #!((defined __GLIBC__ \
>>>      || (defined __NEWLIB__ \
>>>      && ((__NEWLIB__ == 2 && __NEWLIB_MINOR__ >= 4) || __NEWLIB__ >= 3))) \
>>>   && !defined __UCLIBC__)
>>>
>>> As for the actual version number to test I have to talk to Jeff if we
>>> can change the version to 2.4 or at least 2.3.1.  2.4 would simplify the
>>> test in gnulib, otherwise the test gets a bit more complicated.
>>
>> Sure, I'll follow up on bug-gnulib as soon as you settle on the version
>> number.
>
> Thank you.  From the thread I take it the version number isn't that
> important anymore?

That's right.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

On Mar 22 08:32, Ken Brown wrote:
> On 3/22/2016 5:30 AM, Corinna Vinschen wrote:
> >On Mar 21 10:13, Ken Brown wrote:
> >>On 3/21/2016 9:06 AM, Corinna Vinschen wrote:
> >>>Hi Ken,
> >>>
> >>>On Mar 21 08:05, Ken Brown wrote:
> >>>>On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
> >>>>>On 2016-03-20 12:29, Ken Brown wrote:
> >>>>>>>>Never mind.  I just sent a report to bug-gnulib, so you can follow up
> >>>>>>>>there.
> >>>>>>
> >>>>>>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.
> >>>>>
> >>>>>Treating Cygwin just like glibc should generally be the solution.
> >>>>
> >>>>The problem is now fixed in upstream Gnulib.
> >>>
> >>>I just read the thread and it occured to me that this doesn't only
> >>>affect Cygwin, but all systems using newlib starting with the next
> >>>version of newlib.
> >>>
> >>>That reminds me that we have to bump newlib's version about now.
> >>>
> >>>Would you mind to follow up with that problem on bug-gnulib?  The test
> >>>should probably look like this, more or less:
> >>>
> >>>#!((defined __GLIBC__ \
> >>>     || (defined __NEWLIB__ \
> >>>     && ((__NEWLIB__ == 2 && __NEWLIB_MINOR__ >= 4) || __NEWLIB__ >= 3))) \
> >>>  && !defined __UCLIBC__)
> >>>
> >>>As for the actual version number to test I have to talk to Jeff if we
> >>>can change the version to 2.4 or at least 2.3.1.  2.4 would simplify the
> >>>test in gnulib, otherwise the test gets a bit more complicated.
> >>
> >>Sure, I'll follow up on bug-gnulib as soon as you settle on the version
> >>number.
> >
> >Thank you.  From the thread I take it the version number isn't that
> >important anymore?
> 
> That's right.

FYI, we bumped newlib to 2.4.0 anyway.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Ken Brown]

On 3/30/2016 8:51 AM, Corinna Vinschen wrote:
> On Mar 22 08:32, Ken Brown wrote:
>> On 3/22/2016 5:30 AM, Corinna Vinschen wrote:
>>> On Mar 21 10:13, Ken Brown wrote:
>>>> On 3/21/2016 9:06 AM, Corinna Vinschen wrote:
>>>>> Hi Ken,
>>>>>
>>>>> On Mar 21 08:05, Ken Brown wrote:
>>>>>> On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
>>>>>>> On 2016-03-20 12:29, Ken Brown wrote:
>>>>>>>>>> Never mind.  I just sent a report to bug-gnulib, so you can follow up
>>>>>>>>>> there.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> Treating Cygwin just like glibc should generally be the solution.
>>>>>>
>>>>>> The problem is now fixed in upstream Gnulib.
>>>>>
>>>>> I just read the thread and it occured to me that this doesn't only
>>>>> affect Cygwin, but all systems using newlib starting with the next
>>>>> version of newlib.
>>>>>
>>>>> That reminds me that we have to bump newlib's version about now.
>>>>>
>>>>> Would you mind to follow up with that problem on bug-gnulib?  The test
>>>>> should probably look like this, more or less:
>>>>>
>>>>> #!((defined __GLIBC__ \
>>>>>      || (defined __NEWLIB__ \
>>>>>      && ((__NEWLIB__ == 2 && __NEWLIB_MINOR__ >= 4) || __NEWLIB__ >= 3))) \
>>>>>   && !defined __UCLIBC__)
>>>>>
>>>>> As for the actual version number to test I have to talk to Jeff if we
>>>>> can change the version to 2.4 or at least 2.3.1.  2.4 would simplify the
>>>>> test in gnulib, otherwise the test gets a bit more complicated.
>>>>
>>>> Sure, I'll follow up on bug-gnulib as soon as you settle on the version
>>>> number.
>>>
>>> Thank you.  From the thread I take it the version number isn't that
>>> important anymore?
>>
>> That's right.
>
> FYI, we bumped newlib to 2.4.0 anyway.

OK, good to know.  I've agreed to look through the gnulib sources for 
other places where 'defined __CYGWIN__' should be replaced by 'defined 
__NEWLIB__', so the version check may turn out to be needed.

Ken

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Yaakov Selkowitz]

On 2016-03-19 05:32, Corinna Vinschen wrote:
> 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?

If you want, but with the implementation of _DEFAULT_SOURCE (since glibc 
2.20), there is no functional difference between BSD, SVID, and MISC; 
it's mostly historical and documentative at this point.

> I guess we won't get off without toothing aches :}

It seems not. :-(

-- 
Yaakov

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Mar 19 23:49, Yaakov Selkowitz wrote:
> On 2016-03-19 05:32, Corinna Vinschen wrote:
> >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?
> 
> If you want, but with the implementation of _DEFAULT_SOURCE (since glibc
> 2.20), there is no functional difference between BSD, SVID, and MISC; it's
> mostly historical and documentative at this point.

It might be helpful to align this with glibc, even if it's just to
keep the people from puzzeling over the difference.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Achim Gratz]

Corinna Vinschen writes:
>> If so, it might be a good idea for maintainers to test that nothing
>> unexpected happens when they build their packages.
>
> Yes, that's really a good idea.

I've run a fresh build of Perl on this.

- there's a new signal: SIGIOT

- two new symbols are found:  _POSIX_C_SOURCE  _POSIX_SOURCE

- compilation complains about implicit declaration of fseeko and ftello
  (it could have used fseek and ftell since it's a 64bit build).

- eaccess is also implicitly defined

- some math functions are available on 32bit, but not 64bit: acosh,
  asinh, atanh, cbrt, copysign, erf, erfc, expm1, finite, hypot, ilogb,
  j0, lgamma, lgamma_r, log1p, lobg, nan, nextafter, remainder, scalbn
  (this has likely been that way for as long as 64bit exists)

I've also found that the configure script doesn't check correctly for
import libs and thus misses libgdm on 64bit (where only libgdm.dll.a
exists, but not libgdm.a).  On 64bit gdm is also a different version
from 32bit.  What's the expected standard here, really?  Just .dll.a or
both that and .a?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Marco Atzeri]

On 20/03/2016 11:59, Achim Gratz wrote:
> Corinna Vinschen writes:
>>> If so, it might be a good idea for maintainers to test that nothing
>>> unexpected happens when they build their packages.
>>
>> Yes, that's really a good idea.
>
> I've run a fresh build of Perl on this.
>
> - there's a new signal: SIGIOT
>
> - two new symbols are found:  _POSIX_C_SOURCE  _POSIX_SOURCE
>
> - compilation complains about implicit declaration of fseeko and ftello
>    (it could have used fseek and ftell since it's a 64bit build).
>
> - eaccess is also implicitly defined
>
> - some math functions are available on 32bit, but not 64bit: acosh,
>    asinh, atanh, cbrt, copysign, erf, erfc, expm1, finite, hypot, ilogb,
>    j0, lgamma, lgamma_r, log1p, lobg, nan, nextafter, remainder, scalbn
>    (this has likely been that way for as long as 64bit exists)

only for the long double version as in 32 bit

They exist in 2.4.1
asinh
asinhf
casinh
casinhf

>
> I've also found that the configure script doesn't check correctly for
> import libs and thus misses libgdm on 64bit (where only libgdm.dll.a
> exists, but not libgdm.a).  On 64bit gdm is also a different version
> from 32bit.  What's the expected standard here, really?  Just .dll.a or
> both that and .a?

preferred only .dll.a

> Regards,
> Achim.
>

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Mar 20 11:59, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> If so, it might be a good idea for maintainers to test that nothing
> >> unexpected happens when they build their packages.
> >
> > Yes, that's really a good idea.
> 
> I've run a fresh build of Perl on this.
> 
> - there's a new signal: SIGIOT

That's ok and has nothing to do with the FTMs.

> - two new symbols are found:  _POSIX_C_SOURCE  _POSIX_SOURCE

They are defined based on the project's settings.  They are also
set by default if nothing is set by the application, as in glibc.

> - compilation complains about implicit declaration of fseeko and ftello
>   (it could have used fseek and ftell since it's a 64bit build).

There's already a thread on the newlib ML about this one.

> - eaccess is also implicitly defined

eaccess requires setting _GNU_SOURCE.

> - some math functions are available on 32bit, but not 64bit: acosh,
>   asinh, atanh, cbrt, copysign, erf, erfc, expm1, finite, hypot, ilogb,
>   j0, lgamma, lgamma_r, log1p, lobg, nan, nextafter, remainder, scalbn
>   (this has likely been that way for as long as 64bit exists)

These functions are defined on both platforms.  What's *not* defined on
64 bit, but only on 32 bit, are the same functions preceeded with an
underscore, e.g. _copysign.

Can you please check again?  There's something else going wrong here.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Achim Gratz]

Corinna Vinschen writes:
> These functions are defined on both platforms.  What's *not* defined on
> 64 bit, but only on 32 bit, are the same functions preceeded with an
> underscore, e.g. _copysign.
>
> Can you please check again?  There's something else going wrong here.

What's going wrong is that the symbols are also defined in libc.a on
32bit and only in libm.a on 64bit.  The configury for Cygwin removes
both -lc and -lm from the list of libraries that should explicitly be
linked with, a comment is present that both libc and libm symlink to
libcygwin and are implied by gcc anyway.  However that doesn't seem to
be the case anymore on both architectures (these files are not symlinked
and not hardlinked either), but the symbol construction is just
different enough for this not to work on 64bit it would seem.

It works correctly if I don't let the configury check the symbols via nm
in the link libraries, but instead compile a small test program for each
symbol.  That's probably the best solution, all things considered.  It
does not even seem to be that much slower.


As for eaccess: even with the above change, it finds that eaccess is
available in the library when trying to link to the symbol, but doesn't
notice that it's not actually defined during compilation.  So I'm adding
_GNU_SOURCE to the flags (yup, that works just fine).


Last but not least the Win32 and Win32-API modules have trouble with
including the right files to get at wcslen and wcscpy.  This is what
these sources do to apparently get at those symbols:

--8<---------------cut here---------------start------------->8---
#define WIN32_LEAN_AND_MEAN
#include <wctype.h>
#include <windows.h>
#include <shlobj.h>
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
#define  WIN32_LEAN_AND_MEAN	/* Tell windows.h to skip much */
#include <windows.h>
#include <winioctl.h>
--8<---------------cut here---------------end--------------->8---

What needs to be defined and/or included to get these?  From the
MSDN documentation one would think that either string.h or wchar.h
should do it, but is one of those preferrable?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

On Mar 20 19:19, Achim Gratz wrote:
> Corinna Vinschen writes:
> > These functions are defined on both platforms.  What's *not* defined on
> > 64 bit, but only on 32 bit, are the same functions preceeded with an
> > underscore, e.g. _copysign.
> >
> > Can you please check again?  There's something else going wrong here.
> 
> What's going wrong is that the symbols are also defined in libc.a on
> 32bit and only in libm.a on 64bit.  The configury for Cygwin removes
> both -lc and -lm from the list of libraries that should explicitly be
> linked with, a comment is present that both libc and libm symlink to
> libcygwin and are implied by gcc anyway.  However that doesn't seem to
> be the case anymore on both architectures (these files are not symlinked
> and not hardlinked either), but the symbol construction is just
> different enough for this not to work on 64bit it would seem.

No, that's not quite it.  The problem is that on 32 bit the
*underscored* functions are exported by libc.a.  This is an accident,
and probably one which is many years old.  Here's what's exported by
libm.a:

  nm libm.a | grep copysign
	   U __imp__copysign
  00000000 T _copysign
	   U __imp__copysignf
  00000000 T _copysignf

And here's what's exported on 32 bit by libc.a.  Note the extra leading
underscore:

  $ nm libc.a | grep copysign
  00000000 T __copysign
	   U __imp___copysign
  00000000 T __copysignf
	   U __imp___copysignf

These underscored versions were always exported additionally by the 32
bit version but they have never been exported on 64 bit since exporting
them was wrong from the start.

> It works correctly if I don't let the configury check the symbols via nm
> in the link libraries, but instead compile a small test program for each
> symbol.  That's probably the best solution, all things considered.  It
> does not even seem to be that much slower.

The nm expression apparently finds the underscored versions even though
it shouldn't.

> Last but not least the Win32 and Win32-API modules have trouble with
> including the right files to get at wcslen and wcscpy.  This is what
> these sources do to apparently get at those symbols:
> 
> --8<---------------cut here---------------start------------->8---
> #define WIN32_LEAN_AND_MEAN
> #include <wctype.h>
> #include <windows.h>
> #include <shlobj.h>
> --8<---------------cut here---------------end--------------->8---
> 
> --8<---------------cut here---------------start------------->8---
> #define  WIN32_LEAN_AND_MEAN	/* Tell windows.h to skip much */
> #include <windows.h>
> #include <winioctl.h>
> --8<---------------cut here---------------end--------------->8---
> 
> What needs to be defined and/or included to get these?  From the
> MSDN documentation one would think that either string.h or wchar.h
> should do it, but is one of those preferrable?

Per POSIX it's wchar.h.  If you compile these modules using Cygwin GCC,
it will find the cygwin headers, of course.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

On Mar 20 21:45, Corinna Vinschen wrote:
> On Mar 20 19:19, Achim Gratz wrote:
> > What's going wrong is that the symbols are also defined in libc.a on
> > 32bit and only in libm.a on 64bit.  The configury for Cygwin removes
> > both -lc and -lm from the list of libraries that should explicitly be
> > linked with, a comment is present that both libc and libm symlink to
> > libcygwin and are implied by gcc anyway.  However that doesn't seem to
> > be the case anymore on both architectures (these files are not symlinked
> > and not hardlinked either), but the symbol construction is just
> > different enough for this not to work on 64bit it would seem.
> 
> No, that's not quite it.  The problem is that on 32 bit the
> *underscored* functions are exported by libc.a.  This is an accident,
> and probably one which is many years old.  Here's what's exported by
> libm.a:
> 
>   nm libm.a | grep copysign
> 	   U __imp__copysign
>   00000000 T _copysign
> 	   U __imp__copysignf
>   00000000 T _copysignf
> 
> And here's what's exported on 32 bit by libc.a.  Note the extra leading
> underscore:
> 
>   $ nm libc.a | grep copysign
>   00000000 T __copysign
> 	   U __imp___copysign
>   00000000 T __copysignf
> 	   U __imp___copysignf
> 
> These underscored versions were always exported additionally by the 32
> bit version but they have never been exported on 64 bit since exporting
> them was wrong from the start.

I'd like to get rid of them but the 32 bit versions has to stick to
them for backward compat.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Achim Gratz]

Corinna Vinschen writes:
>> - eaccess is also implicitly defined
>
> eaccess requires setting _GNU_SOURCE.

Doing that seems to have changed the behaviour of sprintf and now one of
the tests involving NaN and the %a format fails.  Ideas?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Yaakov Selkowitz]

On 2016-03-20 14:04, Achim Gratz wrote:
> Corinna Vinschen writes:
>>> - eaccess is also implicitly defined
>>
>> eaccess requires setting _GNU_SOURCE.
>
> Doing that seems to have changed the behaviour of sprintf and now one of
> the tests involving NaN and the %a format fails.  Ideas?

Can you be more specific?

-- 
Yaakov

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Achim Gratz]

Yaakov Selkowitz writes:
> On 2016-03-20 14:04, Achim Gratz wrote:
>> Doing that seems to have changed the behaviour of sprintf and now one of
>> the tests involving NaN and the %a format fails.  Ideas?
>
> Can you be more specific?

The error is this:

--8<---------------cut here---------------start------------->8---
Failed test 346 - NaN sprintf %a is NaN at op/infnan.t line 303
#      got "0x1.8p-1"
# expected "NaN"
--8<---------------cut here---------------end--------------->8---

It _is_ definitely related to defining _GNU_SOURCE, so hopefully that
gives a clue as to where it's happening.  I've just switched the second
machine back to Cygwin 2.4.1 to see if it was somehow one of the newlib
changes in 2.5.0, but it's not.  I have no idea yet how _GNU_SOURCE
figures into the issue, only that Perl sprintf is a big hairball of
workarounds for various system implementations (and for the test in
question involving %a format probably doesn't even use the system/newlib
sprintf).

I've ran out of time, I will build without _GNU_SOURCE again tomorrow
and see if that produces any differences in config.h that are notable.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Dodgy functions (was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8)

[Achim Gratz]

Yaakov Selkowitz writes:
>> Doing that seems to have changed the behaviour of sprintf and now one of
>> the tests involving NaN and the %a format fails.  Ideas?
>
> Can you be more specific?

I've finally drilled to the bottom of this (on 64bit so far, but the
issues and workarounds are quite likely similar on 32bit).  One part of
the problem was that not all symbols are accessible via the import
libraries libc.a and libm.a (sys_errlst and tzname get recognized
additionally if you look at libcygwin.a) .  The second part of the
problem is that finite and finitel seem to not work correctly.  These
get picked up when I either extract symbols from libm.a, libcygwin.a or
let Configure check for the presence of those symbols with a test
program instead of nm (which picks them up from libcygwin presumably).
Long story short, they seem to report a finite value on at least some
NaN constructs and then the %a format for the Perl sprintf outputs those
bits as a hex FP number rather than just printing "NaN".  On 64bit the
culprit is actually finitel, of course, since Perl gets compiled with
long doubles.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Dodgy functions

[Achim Gratz]

Achim Gratz writes:
> Long story short, they seem to report a finite value on at least some
> NaN constructs and then the %a format for the Perl sprintf outputs those
> bits as a hex FP number rather than just printing "NaN".  On 64bit the
> culprit is actually finitel, of course, since Perl gets compiled with
> long doubles.

And looking into newlib this seems to be a compile bug, because the
function just uses an intrinsic.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Dodgy functions (finitel, strold)

[Achim Gratz]

Achim Gratz writes:
> Achim Gratz writes:
>> Long story short, they seem to report a finite value on at least some
>> NaN constructs and then the %a format for the Perl sprintf outputs those
>> bits as a hex FP number rather than just printing "NaN".  On 64bit the
>> culprit is actually finitel, of course, since Perl gets compiled with
>> long doubles.
>
> And looking into newlib this seems to be a compile bug, because the
> function just uses an intrinsic.

But the compiler is innocent, because newlib uses the wrong intrinsic or
an incomplete implementation.  If it must be using that intrinsic for
compatibility reasons, it would need to implement

--8<---------------cut here---------------start------------->8---
return (x == x) ? (__builtin_isinf_sign (x) == 0) : 0;
--8<---------------cut here---------------end--------------->8---

so it doesn't report NaN as finite.  NaN compares unequal even with
itself, so the first part implements !isnan(x).  But it should really
just use

--8<---------------cut here---------------start------------->8---
return __builtin_isfinite;
--8<---------------cut here---------------end--------------->8---

provided that is available from all targeted compilers.

So it's a newlib bug.  But for whatever reason I couldn't make it appear
in a simple test case, most likely because gcc somehow recognized
something about it and replaced it with the correct version when
compiling with the standard options, so it never links in the wrong
newlib implementation.  However, compiling with -std=c89 (like Perl)
finally teases it out.

I've extended the test program from Corinna so it compiles with both
options and doesn't crash with no input.  This also uncovered a separate
bug with strtold (which is only available in C99 mode).

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
 
int
test_infsgn (double x)
{
  return __builtin_isinf_sign (x) == 0;
}
 
int
test_infsgnl (long double x)
{
  return __builtin_isinf_sign (x) == 0;
}
 
int
test_finite (double x)
{
  return __builtin_isfinite (x);
}
 
int
test_finitel (long double x)
{
  return __builtin_isfinite (x);
}
 
int
main (int argc, char **argv)
{
  printf ("===== got %d argument(s)\n", argc);
  int i=0;
  while (++i < argc) {
    double a = strtod (argv[i], NULL);
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
    long double b = strtold (argv[i], NULL);
#endif
    long double c = a;
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
    printf ("===== arg[%d] = (double) %a = (long double) %La = (long double)(double) %La\n", i, a, b, c);
#else
    printf ("===== arg[%d] = (double) %a = (long double)(double) %La\n", i, a, c);
#endif
    printf ("infsgn:              (double) %d\n", test_infsgn (a));
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
    printf ("infsgn:         (long double) %d\n", test_infsgnl (b));
#endif
    printf ("infsgn: (long double)(double) %d\n", test_infsgnl (c));
    printf ("finite:              (double) %d\n", test_finite (a));
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
    printf ("finite:         (long double) %d\n", test_finitel (b));
#endif
    printf ("finite: (long double)(double) %d\n", test_finitel (c));
    printf ("newlib:              (double) %d\n", finite (a));
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
    printf ("newlib:         (long double) %d\n", finitel (b));
#endif
    printf ("newlib: (long double)(double) %d\n", finitel (c));
  }
  printf ("===== ran out of args\n");
  return 0;
}
--8<---------------cut here---------------end--------------->8---

Compilation with C89 showing the newlib bug:

--8<---------------cut here---------------start------------->8---
$ gcc -std=c89 infnan.c -o infnan && ./infnan 1 nan -inf +inf
===== got 5 argument(s)
===== arg[1] = (double) 0x1p+0 = (long double)(double) 0x1p+0
infsgn:              (double) 1
infsgn: (long double)(double) 1
finite:              (double) 1
finite: (long double)(double) 1
newlib:              (double) 1
newlib: (long double)(double) 1
===== arg[2] = (double) nan = (long double)(double) nan
infsgn:              (double) 1
infsgn: (long double)(double) 1
finite:              (double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib: (long double)(double) 1
===== arg[3] = (double) -inf = (long double)(double) -inf
infsgn:              (double) 0
infsgn: (long double)(double) 0
finite:              (double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib: (long double)(double) 0
===== arg[4] = (double) inf = (long double)(double) inf
infsgn:              (double) 0
infsgn: (long double)(double) 0
finite:              (double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib: (long double)(double) 0
===== ran out of args
--8<---------------cut here---------------end--------------->8---

Compilation with C99 showing that strtold still doesn't work correctly
(it folds Inf->NaN):

--8<---------------cut here---------------start------------->8---
 gcc -std=c99 infnan.c -o infnan && ./infnan 1 nan -inf +inf
===== got 5 argument(s)
===== arg[1] = (double) 0x1p+0 = (long double) 0x1p+0 = (long double)(double) 0x1p+0
infsgn:              (double) 1
infsgn:         (long double) 1
infsgn: (long double)(double) 1
finite:              (double) 1
finite:         (long double) 1
finite: (long double)(double) 1
newlib:              (double) 1
newlib:         (long double) 1
newlib: (long double)(double) 1
===== arg[2] = (double) nan = (long double) nan = (long double)(double) nan
infsgn:              (double) 1
infsgn:         (long double) 1
infsgn: (long double)(double) 1
finite:              (double) 0
finite:         (long double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib:         (long double) 1
newlib: (long double)(double) 1
===== arg[3] = (double) -inf = (long double) nan = (long double)(double) -inf
infsgn:              (double) 0
infsgn:         (long double) 1
infsgn: (long double)(double) 0
finite:              (double) 0
finite:         (long double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib:         (long double) 1
newlib: (long double)(double) 0
===== arg[4] = (double) inf = (long double) nan = (long double)(double) inf
infsgn:              (double) 0
infsgn:         (long double) 1
infsgn: (long double)(double) 0
finite:              (double) 0
finite:         (long double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib:         (long double) 1
newlib: (long double)(double) 0
===== ran out of args
--8<---------------cut here---------------end--------------->8---

Finally, here's gcc making a run-around the bug in newlib (it was no fun
finding _that_, since it cost me two days of sleuthing to recognize that
I'd been lied to by the test program):

--8<---------------cut here---------------start------------->8---
$ gcc infnan.c -o infnan && ./infnan 1 nan -inf +inf
===== got 5 argument(s)
===== arg[1] = (double) 0x1p+0 = (long double) 0x1p+0 = (long double)(double) 0x1p+0
infsgn:              (double) 1
infsgn:         (long double) 1
infsgn: (long double)(double) 1
finite:              (double) 1
finite:         (long double) 1
finite: (long double)(double) 1
newlib:              (double) 1
newlib:         (long double) 1
newlib: (long double)(double) 1
===== arg[2] = (double) nan = (long double) nan = (long double)(double) nan
infsgn:              (double) 1
infsgn:         (long double) 1
infsgn: (long double)(double) 1
finite:              (double) 0
finite:         (long double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib:         (long double) 0
newlib: (long double)(double) 0
===== arg[3] = (double) -inf = (long double) nan = (long double)(double) -inf
infsgn:              (double) 0
infsgn:         (long double) 1
infsgn: (long double)(double) 0
finite:              (double) 0
finite:         (long double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib:         (long double) 0
newlib: (long double)(double) 0
===== arg[4] = (double) inf = (long double) nan = (long double)(double) inf
infsgn:              (double) 0
infsgn:         (long double) 1
infsgn: (long double)(double) 0
finite:              (double) 0
finite:         (long double) 0
finite: (long double)(double) 0
newlib:              (double) 0
newlib:         (long double) 0
newlib: (long double)(double) 0
===== ran out of args
--8<---------------cut here---------------end--------------->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Dodgy functions (finitel, strold)

[Doug Henderson]

On 25 March 2016 at 02:59, Achim Gratz <Stromeko@nexgo.de> wrote:
>
> Achim Gratz writes:
> > Achim Gratz writes:
> >> Long story short, they seem to report a finite value on at least some
> >> NaN constructs and then the %a format for the Perl sprintf outputs those
> >> bits as a hex FP number rather than just printing "NaN".  On 64bit the
> >> culprit is actually finitel, of course, since Perl gets compiled with
> >> long doubles.
> >
> > And looking into newlib this seems to be a compile bug, because the
> > function just uses an intrinsic.
>
> But the compiler is innocent, because newlib uses the wrong intrinsic or
> an incomplete implementation.  If it must be using that intrinsic for
> compatibility reasons, it would need to implement
>
> <snip>
>
> Regards,
> Achim.
>


I modified your program to display the actual hex value of the a, b,
and c variables. The b and c variables have different bit patterns. It
appears that the %a format conversion is (correctly) detecting ±inf
and NaN according to IEEE 754, and ignoring the value of all other
bits in the variables.

It appears that strtold and the implicit conversion from double to
long double are setting some of the bits which are not used to
represent NaN or ±Inf to different values.

It appears that some of the different functions that get used to
detect finiteness and validity are sensitive to the setting of other
bits in the values, or are expecting particular values for these bits.

The standard supports two representations of NaN: a signalling NaN and
a non-signalling NaN. From what I could see, the C language does not
distinguish between the two NaN representations, but I did not look at
the standards docs.

HTH,
Doug


-- 
Doug Henderson, Calgary, Alberta, Canada

Re: Dodgy functions (finitel, strold)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Mar 25 18:16, Doug Henderson wrote:
> On 25 March 2016 at 02:59, Achim Gratz <Stromeko@nexgo.de> wrote:
> >
> > Achim Gratz writes:
> > > Achim Gratz writes:
> > >> Long story short, they seem to report a finite value on at least some
> > >> NaN constructs and then the %a format for the Perl sprintf outputs those
> > >> bits as a hex FP number rather than just printing "NaN".  On 64bit the
> > >> culprit is actually finitel, of course, since Perl gets compiled with
> > >> long doubles.
> > >
> > > And looking into newlib this seems to be a compile bug, because the
> > > function just uses an intrinsic.
> >
> > But the compiler is innocent, because newlib uses the wrong intrinsic or
> > an incomplete implementation.  If it must be using that intrinsic for
> > compatibility reasons, it would need to implement
> >
> > <snip>
> >
> > Regards,
> > Achim.
> >
> 
> 
> I modified your program to display the actual hex value of the a, b,
> and c variables. The b and c variables have different bit patterns. It
> appears that the %a format conversion is (correctly) detecting ±inf
> and NaN according to IEEE 754, and ignoring the value of all other
> bits in the variables.
> 
> It appears that strtold and the implicit conversion from double to
> long double are setting some of the bits which are not used to
> represent NaN or ±Inf to different values.

strtold actually forgot to set one bit.

I now fixed finitel, the return value of strtold for +/-infinity,
and I improved math.h by using GCC builtins for the C99 macros
which makes them type agnostic and thus lon double aware.

Building a snaphot right now.  Please give it a try.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Dodgy functions (finitel, strold)

[Achim Gratz]

Doug Henderson writes:
> I modified your program to display the actual hex value of the a, b,
> and c variables. The b and c variables have different bit patterns. It
> appears that the %a format conversion is (correctly) detecting ±inf
> and NaN according to IEEE 754, and ignoring the value of all other
> bits in the variables.

I wasn't concerned about the bit patterns, but the fact that +-Inf was
recognized as valid input, but then converted to NaN.

> It appears that strtold and the implicit conversion from double to
> long double are setting some of the bits which are not used to
> represent NaN or ±Inf to different values.
>
> It appears that some of the different functions that get used to
> detect finiteness and validity are sensitive to the setting of other
> bits in the values, or are expecting particular values for these bits.

That would be a bug.  The standard defines all the valid bit patterns
for each case, so if in doubt you could exhaustively test them.

> The standard supports two representations of NaN: a signalling NaN and
> a non-signalling NaN. From what I could see, the C language does not
> distinguish between the two NaN representations, but I did not look at
> the standards docs.

You can mostly ignore that distinction unless the runtime exposes it to
you.  In a nutshell, the difference is between silently producing and
then using the NaN in further computation or raising an exception.  In
the latter case, the runtime would need to give you a way to catch and
handle the exception.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Chris Sutcliffe]

On 18 March 2016 at 17:45, Corinna Vinschen wrote:
>
> [CCed cygwin-apps to reach out to all package maintainers]
>
> On Mar 18 16:58, Ken Brown wrote:
>> If
>> so, it might be a good idea for maintainers to test that nothing unexpected
>> happens when they build their packages.
>
> Yes, that's really a good idea.

FWIW, mksh builds and runs fine with this test release.

Cheers,

Chris

--
Chris Sutcliffe

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On Mar 22 11:16, Chris Sutcliffe wrote:
> On 18 March 2016 at 17:45, Corinna Vinschen wrote:
> >
> > [CCed cygwin-apps to reach out to all package maintainers]
> >
> > On Mar 18 16:58, Ken Brown wrote:
> >> If
> >> so, it might be a good idea for maintainers to test that nothing unexpected
> >> happens when they build their packages.
> >
> > Yes, that's really a good idea.
> 
> FWIW, mksh builds and runs fine with this test release.

Good to know.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]