Windows build fails -- again!
Andreas Voellmy
andreas.voellmy at gmail.com
Sat Aug 23 17:20:34 UTC 2014
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 <austin at well-typed.com> 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
> <andreas.voellmy at gmail.com> 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 <kyrab at mail.ru> 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'; 'ghc-devs at haskell.org'; '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; ghc-devs at haskell.org
> >>> | | 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:ggreif at gmail.com]
> >>> | | | 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 <simonpj at microsoft.com> 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
> >>> ghc-devs at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>>
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140823/d95341e8/attachment.html>
More information about the ghc-devs
mailing list