I think the problem with the commit was that setIOManagerControlFd() was defined for all OS types, whereas the prototype was defined only when mingw32_HOST_OS is not defined.I think the resolution is to only define setIOManagerControlFd when mingw32_HOST_OS is not defined, since if I understand correctly, on Windows we don't use the IO manager in GHC.Event anyway.
I created a Phab diff that reverts the revert of the original commit and also fixes it as explained above. I tried to update the previous diff (D129), but I couldn't because it is closed. So I created a new one (D174). Austin: can you help me validate it on Windows? I don't have a Windows machine available. The patch also avoids defining the io_manager_control_wr_fd field in Capability struct when mingw32_HOST_OS is not defined. While we are at it, where should the prototype for setIOManagerControlFd be? It is currently in includes/rts/IOManager.h, whereas the function is defined in rts/Schedule.c. Should the prototype be moved to rts/Schedule.h? Or should the setIOManagerControlFd definition be moved somewhere else instead? Andi On Fri, Aug 22, 2014 at 5:01 PM, Austin Seipp <[email protected]> wrote: > I've reverted it in the mean time > (4748f5936fe72d96edfa17b153dbfd84f2c4c053), sorry about that. I've > spent some time working on a Windows Phabricator machine, so stay > tuned! > > Andreas, if you need a Windows VM or something temporarily to test, do > let me know. > > On Fri, Aug 22, 2014 at 4:00 PM, Andreas Voellmy > <[email protected]> wrote: > > I'm just noticing this thread now... sorry about the delay and the > problems! > > I'll look into what happened here. > > > > > > On Fri, Aug 22, 2014 at 8:04 AM, kyra <[email protected]> wrote: > >> > >> I've looked into this patch, it looks like this patch was intended to > >> touch only linuxish IO Manager, but in fact it touched common (os > unrelated) > >> code here and there extensively and there are almost no chances somebody > >> else (not the author) can fix the things. > >> > >> So, almost the only way to unbreak the build it to revert the patch. > >> > >> Regards, > >> Kyra > >> > >> > >> On 8/22/2014 16:07, Simon Peyton Jones wrote: > >>> > >>> Friends > >>> > >>> My Windows build is still broken, and has been since Andreas's patch > >>> commit f9f89b7884ccc8ee5047cf4fffdf2b36df6832df > >>> on Tues 19th. > >>> > >>> Please can someone help? I'm begging. > >>> > >>> I suppose that if I hear nothing I can simply revert his patch but that > >>> seems like the Wrong Solution > >>> > >>> Thanks > >>> > >>> Simon > >>> > >>> | -----Original Message----- > >>> | From: Simon Peyton Jones > >>> | Sent: 20 August 2014 23:48 > >>> | To: 'Gabor Greif'; '[email protected]'; 'Andreas Voellmy' > >>> | Subject: RE: Windows build fails -- again! > >>> | > >>> | Help! My Windows build is still falling over as below. > >>> | > >>> | Andreas, you seem to be the author of the commit that broke this. > I'd > >>> | really appreciate a fix. (From anyone!) > >>> | > >>> | thank you > >>> | > >>> | Simon > >>> | > >>> | | -----Original Message----- > >>> | | From: Simon Peyton Jones > >>> | | Sent: 20 August 2014 09:26 > >>> | | To: Gabor Greif; [email protected] > >>> | | Subject: RE: Windows build fails -- again! > >>> | | > >>> | | Thanks Gabor. But it makes no difference. Your change is inside > an > >>> | | #ifdef that checks for windows, and your change is in the > no-windows > >>> | | branch only. > >>> | | > >>> | | Also there are two IOManager.h file > >>> | | includes/rts/IOManager.h > >>> | | rts/win32/IOManager.h > >>> | | > >>> | | Should there be? It seems terribly confusing, and I have no idea > >>> which > >>> | | will win when it is #included. > >>> | | > >>> | | Thanks > >>> | | > >>> | | Simon > >>> | | > >>> | | | -----Original Message----- > >>> | | | From: Gabor Greif [mailto:[email protected]] > >>> | | | Sent: 19 August 2014 23:38 > >>> | | | To: Simon Peyton Jones > >>> | | | Subject: Re: Windows build fails -- again! > >>> | | | > >>> | | | Simon, > >>> | | | > >>> | | | try this (attached) patch: > >>> | | | > >>> | | | $ git am 0001-Make-sure-that-a-prototype-is-included-for- > >>> | | | setIOMana.patch > >>> | | | > >>> | | | Cheers, > >>> | | | > >>> | | | Gabor > >>> | | | > >>> | | | PS: on MacOS all is good, so I could not test it at all > >>> | | | > >>> | | | On 8/20/14, Simon Peyton Jones <[email protected]> wrote: > >>> | | | > Aaargh! My windows build is broken, again. > >>> | | | > It's very painful that this keeps happening. > >>> | | | > Can anyone help? > >>> | | | > Simon > >>> | | | > > >>> | | | > "inplace/bin/ghc-stage1.exe" -optc-U__i686 -optc-march=i686 > >>> | | | > -optc-fno-stack-protector -optc-Werror -optc-Wall -optc-Wall > >>> | | | > -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes > >>> | | | > -optc-Wmissing-declarations -optc-Winline > -optc-Waggregate-return > >>> | | | > -optc-Wpointer-arith -optc-Wmissing-noreturn > >>> -optc-Wnested-externs > >>> | | | > -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist > >>> | | | > -optc-Iincludes/dist-derivedconstants/header > >>> | | | > -optc-Iincludes/dist-ghcconstants/header -optc-Irts > >>> | | | > -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict- > >>> | aliasing > >>> | | | > -optc-fno-common -optc-O2 -optc-fomit-frame-pointer > >>> | | | > -optc-DRtsWay=\"rts_v\" -static -H32m -O -Werror -Wall -H64m > -O0 > >>> | | | > -Iincludes -Iincludes/dist > >>> -Iincludes/dist-derivedconstants/header > >>> | | | > -Iincludes/dist-ghcconstants/header > >>> | | | > -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts > >>> | | | > -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen - > >>> | | | Irts/dist/build > >>> | | | > -Irts/dist/build/autogen -O2 -c rts/Task.c -o > >>> | | | > rts/dist/build/Task.o > >>> | | | > > >>> | | | > cc1.exe: warnings being treated as errors > >>> | | | > > >>> | | | > > >>> | | | > > >>> | | | > rts\Capability.c:1080:6: > >>> | | | > > >>> | | | > error: no previous prototype for 'setIOManagerControlFd' > >>> | | | > > >>> | | | > rts/ghc.mk:236: recipe for target > 'rts/dist/build/Capability.o' > >>> | | | failed > >>> | | | > > >>> | | | > make[1]: *** [rts/dist/build/Capability.o] Error 1 > >>> | | | > > >>> | | | > make[1]: *** Waiting for unfinished jobs.... > >>> | | | > > >>> | | | > Makefile:71: recipe for target 'all' failed > >>> | | | > > >>> | | | > make: *** [all] Error 2 > >>> | | | > > >>> | | | > HEAD (master)$ > >>> | | | > > >>> | | | > > >>> | | | > > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> [email protected] > >>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>> > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> [email protected] > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > > > _______________________________________________ > > ghc-devs mailing list > > [email protected] > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
