* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 [not found] ` <56EC6BDA.7050505@cornell.edu> @ 2016-03-18 21:45 ` Corinna Vinschen 2016-03-18 22:25 ` Ken Brown ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Corinna Vinschen @ 2016-03-18 21:45 UTC (permalink / raw) To: cygwin; +Cc: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-18 21:45 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Corinna Vinschen @ 2016-03-18 22:25 ` Ken Brown 2016-03-18 22:40 ` Ken Brown 2016-03-18 23:05 ` Yaakov Selkowitz 2016-03-20 10:59 ` Achim Gratz 2016-03-22 17:43 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Chris Sutcliffe 2 siblings, 2 replies; 40+ messages in thread From: Ken Brown @ 2016-03-18 22:25 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-18 22:25 ` Ken Brown @ 2016-03-18 22:40 ` Ken Brown 2016-03-18 23:05 ` Yaakov Selkowitz 1 sibling, 0 replies; 40+ messages in thread From: Ken Brown @ 2016-03-18 22:40 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-18 22:25 ` Ken Brown 2016-03-18 22:40 ` Ken Brown @ 2016-03-18 23:05 ` Yaakov Selkowitz 2016-03-18 23:29 ` Yaakov Selkowitz 1 sibling, 1 reply; 40+ messages in thread From: Yaakov Selkowitz @ 2016-03-18 23:05 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-18 23:05 ` Yaakov Selkowitz @ 2016-03-18 23:29 ` Yaakov Selkowitz 2016-03-19 2:24 ` Ken Brown 0 siblings, 1 reply; 40+ messages in thread From: Yaakov Selkowitz @ 2016-03-18 23:29 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-18 23:29 ` Yaakov Selkowitz @ 2016-03-19 2:24 ` Ken Brown 2016-03-19 10:32 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Ken Brown @ 2016-03-19 2:24 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-19 2:24 ` Ken Brown @ 2016-03-19 10:32 ` Corinna Vinschen 2016-03-19 12:34 ` Ken Brown 2016-03-20 4:50 ` Yaakov Selkowitz 0 siblings, 2 replies; 40+ messages in thread From: Corinna Vinschen @ 2016-03-19 10:32 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-19 10:32 ` Corinna Vinschen @ 2016-03-19 12:34 ` Ken Brown 2016-03-19 18:03 ` Ken Brown 2016-03-20 4:50 ` Yaakov Selkowitz 1 sibling, 1 reply; 40+ messages in thread From: Ken Brown @ 2016-03-19 12:34 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-19 12:34 ` Ken Brown @ 2016-03-19 18:03 ` Ken Brown 2016-03-20 15:26 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Ken Brown @ 2016-03-19 18:03 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-19 18:03 ` Ken Brown @ 2016-03-20 15:26 ` Corinna Vinschen 2016-03-20 19:27 ` Ken Brown 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2016-03-20 15:26 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 15:26 ` Corinna Vinschen @ 2016-03-20 19:27 ` Ken Brown 2016-03-20 19:40 ` Ken Brown ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Ken Brown @ 2016-03-20 19:27 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 19:27 ` Ken Brown @ 2016-03-20 19:40 ` Ken Brown 2016-03-20 20:18 ` Ken Brown 2016-03-20 20:47 ` Yaakov Selkowitz 2 siblings, 0 replies; 40+ messages in thread From: Ken Brown @ 2016-03-20 19:40 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 19:27 ` Ken Brown 2016-03-20 19:40 ` Ken Brown @ 2016-03-20 20:18 ` Ken Brown 2016-03-20 20:47 ` Yaakov Selkowitz 2 siblings, 0 replies; 40+ messages in thread From: Ken Brown @ 2016-03-20 20:18 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 19:27 ` Ken Brown 2016-03-20 19:40 ` Ken Brown 2016-03-20 20:18 ` Ken Brown @ 2016-03-20 20:47 ` Yaakov Selkowitz 2016-03-21 14:13 ` Ken Brown 2 siblings, 1 reply; 40+ messages in thread From: Yaakov Selkowitz @ 2016-03-20 20:47 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 20:47 ` Yaakov Selkowitz @ 2016-03-21 14:13 ` Ken Brown 2016-03-21 16:30 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Ken Brown @ 2016-03-21 14:13 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-21 14:13 ` Ken Brown @ 2016-03-21 16:30 ` Corinna Vinschen 2016-03-21 17:59 ` Ken Brown 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2016-03-21 16:30 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-21 16:30 ` Corinna Vinschen @ 2016-03-21 17:59 ` Ken Brown 2016-03-22 11:15 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Ken Brown @ 2016-03-21 17:59 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-21 17:59 ` Ken Brown @ 2016-03-22 11:15 ` Corinna Vinschen 2016-03-22 14:59 ` Ken Brown 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2016-03-22 11:15 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-22 11:15 ` Corinna Vinschen @ 2016-03-22 14:59 ` Ken Brown 2016-03-30 21:17 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Ken Brown @ 2016-03-22 14:59 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-22 14:59 ` Ken Brown @ 2016-03-30 21:17 ` Corinna Vinschen 2016-03-31 11:55 ` Ken Brown 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2016-03-30 21:17 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-30 21:17 ` Corinna Vinschen @ 2016-03-31 11:55 ` Ken Brown 0 siblings, 0 replies; 40+ messages in thread From: Ken Brown @ 2016-03-31 11:55 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-19 10:32 ` Corinna Vinschen 2016-03-19 12:34 ` Ken Brown @ 2016-03-20 4:50 ` Yaakov Selkowitz 2016-03-20 15:18 ` Corinna Vinschen 1 sibling, 1 reply; 40+ messages in thread From: Yaakov Selkowitz @ 2016-03-20 4:50 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 4:50 ` Yaakov Selkowitz @ 2016-03-20 15:18 ` Corinna Vinschen 0 siblings, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2016-03-20 15:18 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-18 21:45 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Corinna Vinschen 2016-03-18 22:25 ` Ken Brown @ 2016-03-20 10:59 ` Achim Gratz 2016-03-20 11:14 ` Marco Atzeri 2016-03-20 15:25 ` Corinna Vinschen 2016-03-22 17:43 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Chris Sutcliffe 2 siblings, 2 replies; 40+ messages in thread From: Achim Gratz @ 2016-03-20 10:59 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 10:59 ` Achim Gratz @ 2016-03-20 11:14 ` Marco Atzeri 2016-03-20 15:25 ` Corinna Vinschen 1 sibling, 0 replies; 40+ messages in thread From: Marco Atzeri @ 2016-03-20 11:14 UTC (permalink / raw) To: cygwin-apps 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. > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 10:59 ` Achim Gratz 2016-03-20 11:14 ` Marco Atzeri @ 2016-03-20 15:25 ` Corinna Vinschen 2016-03-20 19:27 ` Achim Gratz 2016-03-20 20:24 ` Achim Gratz 1 sibling, 2 replies; 40+ messages in thread From: Corinna Vinschen @ 2016-03-20 15:25 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 15:25 ` Corinna Vinschen @ 2016-03-20 19:27 ` Achim Gratz 2016-03-20 20:53 ` Corinna Vinschen 2016-03-20 20:24 ` Achim Gratz 1 sibling, 1 reply; 40+ messages in thread From: Achim Gratz @ 2016-03-20 19:27 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 19:27 ` Achim Gratz @ 2016-03-20 20:53 ` Corinna Vinschen 2016-03-20 21:30 ` Corinna Vinschen 0 siblings, 1 reply; 40+ messages in thread From: Corinna Vinschen @ 2016-03-20 20:53 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 20:53 ` Corinna Vinschen @ 2016-03-20 21:30 ` Corinna Vinschen 0 siblings, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2016-03-20 21:30 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 15:25 ` Corinna Vinschen 2016-03-20 19:27 ` Achim Gratz @ 2016-03-20 20:24 ` Achim Gratz 2016-03-20 20:45 ` Yaakov Selkowitz 1 sibling, 1 reply; 40+ messages in thread From: Achim Gratz @ 2016-03-20 20:24 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 20:24 ` Achim Gratz @ 2016-03-20 20:45 ` Yaakov Selkowitz 2016-03-22 9:31 ` Achim Gratz 2016-03-25 9:00 ` Dodgy functions (was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8) Achim Gratz 0 siblings, 2 replies; 40+ messages in thread From: Yaakov Selkowitz @ 2016-03-20 20:45 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-20 20:45 ` Yaakov Selkowitz @ 2016-03-22 9:31 ` Achim Gratz 2016-03-25 9:00 ` Dodgy functions (was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8) Achim Gratz 1 sibling, 0 replies; 40+ messages in thread From: Achim Gratz @ 2016-03-22 9:31 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Dodgy functions (was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8) 2016-03-20 20:45 ` Yaakov Selkowitz 2016-03-22 9:31 ` Achim Gratz @ 2016-03-25 9:00 ` Achim Gratz 2016-03-26 0:16 ` Dodgy functions Achim Gratz 1 sibling, 1 reply; 40+ messages in thread From: Achim Gratz @ 2016-03-25 9:00 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Dodgy functions 2016-03-25 9:00 ` Dodgy functions (was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8) Achim Gratz @ 2016-03-26 0:16 ` Achim Gratz 2016-03-26 19:41 ` Dodgy functions (finitel, strold) Achim Gratz 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2016-03-26 0:16 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Dodgy functions (finitel, strold) 2016-03-26 0:16 ` Dodgy functions Achim Gratz @ 2016-03-26 19:41 ` Achim Gratz 2016-03-29 16:09 ` Doug Henderson 0 siblings, 1 reply; 40+ messages in thread From: Achim Gratz @ 2016-03-26 19:41 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Dodgy functions (finitel, strold) 2016-03-26 19:41 ` Dodgy functions (finitel, strold) Achim Gratz @ 2016-03-29 16:09 ` Doug Henderson 2016-03-29 16:09 ` Corinna Vinschen 2016-04-01 19:04 ` Achim Gratz 0 siblings, 2 replies; 40+ messages in thread From: Doug Henderson @ 2016-03-29 16:09 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Dodgy functions (finitel, strold) 2016-03-29 16:09 ` Doug Henderson @ 2016-03-29 16:09 ` Corinna Vinschen 2016-04-01 19:04 ` Achim Gratz 1 sibling, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2016-03-29 16:09 UTC (permalink / raw) To: cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Dodgy functions (finitel, strold) 2016-03-29 16:09 ` Doug Henderson 2016-03-29 16:09 ` Corinna Vinschen @ 2016-04-01 19:04 ` Achim Gratz 1 sibling, 0 replies; 40+ messages in thread From: Achim Gratz @ 2016-04-01 19:04 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-18 21:45 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Corinna Vinschen 2016-03-18 22:25 ` Ken Brown 2016-03-20 10:59 ` Achim Gratz @ 2016-03-22 17:43 ` Chris Sutcliffe 2016-03-22 18:02 ` Corinna Vinschen 2 siblings, 1 reply; 40+ messages in thread From: Chris Sutcliffe @ 2016-03-22 17:43 UTC (permalink / raw) To: The Cygwin Mailing List, Cygwin-apps 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 2016-03-22 17:43 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Chris Sutcliffe @ 2016-03-22 18:02 ` Corinna Vinschen 0 siblings, 0 replies; 40+ messages in thread From: Corinna Vinschen @ 2016-03-22 18:02 UTC (permalink / raw) To: cygwin, Cygwin-apps [-- 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 --] ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2016-04-01 19:04 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <announce.20160318203409.GA11113@calimero.vinschen.de> [not found] ` <56EC6BDA.7050505@cornell.edu> 2016-03-18 21:45 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Corinna Vinschen 2016-03-18 22:25 ` Ken Brown 2016-03-18 22:40 ` Ken Brown 2016-03-18 23:05 ` Yaakov Selkowitz 2016-03-18 23:29 ` Yaakov Selkowitz 2016-03-19 2:24 ` Ken Brown 2016-03-19 10:32 ` Corinna Vinschen 2016-03-19 12:34 ` Ken Brown 2016-03-19 18:03 ` Ken Brown 2016-03-20 15:26 ` Corinna Vinschen 2016-03-20 19:27 ` Ken Brown 2016-03-20 19:40 ` Ken Brown 2016-03-20 20:18 ` Ken Brown 2016-03-20 20:47 ` Yaakov Selkowitz 2016-03-21 14:13 ` Ken Brown 2016-03-21 16:30 ` Corinna Vinschen 2016-03-21 17:59 ` Ken Brown 2016-03-22 11:15 ` Corinna Vinschen 2016-03-22 14:59 ` Ken Brown 2016-03-30 21:17 ` Corinna Vinschen 2016-03-31 11:55 ` Ken Brown 2016-03-20 4:50 ` Yaakov Selkowitz 2016-03-20 15:18 ` Corinna Vinschen 2016-03-20 10:59 ` Achim Gratz 2016-03-20 11:14 ` Marco Atzeri 2016-03-20 15:25 ` Corinna Vinschen 2016-03-20 19:27 ` Achim Gratz 2016-03-20 20:53 ` Corinna Vinschen 2016-03-20 21:30 ` Corinna Vinschen 2016-03-20 20:24 ` Achim Gratz 2016-03-20 20:45 ` Yaakov Selkowitz 2016-03-22 9:31 ` Achim Gratz 2016-03-25 9:00 ` Dodgy functions (was: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8) Achim Gratz 2016-03-26 0:16 ` Dodgy functions Achim Gratz 2016-03-26 19:41 ` Dodgy functions (finitel, strold) Achim Gratz 2016-03-29 16:09 ` Doug Henderson 2016-03-29 16:09 ` Corinna Vinschen 2016-04-01 19:04 ` Achim Gratz 2016-03-22 17:43 ` [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8 Chris Sutcliffe 2016-03-22 18:02 ` Corinna Vinschen
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).