- ghc-devs - Haskell.org

Major commit to the constraint solver
by Simon Peyton Jones 04 Nov '14

04 Nov '14

Friends I've pushed branch wip/new-flatten-skolems-Oct14. (It has some rebasing near the top.) It branches off master some a few days ago; i.e. it is almost completely up to date. Can you try building it? I want to push it to HEAD, but would like some independent validation first. Three things don't validate for me: * Several tests fail with ioManagerWakeup problems: reported as Trac #9722 * ghcirun002 experiences stack overflow in the bytecode interpreter, but so does HEAD: Trac #9741 * I get an odd wibble in safePk01, see this thread<https://www.haskell.org/pipermail/ghc-devs/2014-November/007065.html> with Edward I'd like to push to master soon. Thanks Simon

5 8

Re: [GHC] #9358: Improve flag description in the user guide
by Jan Stolarek 04 Nov '14

04 Nov '14

> Jan, you said you'd be willing to do this updating before 7.10 Yes, that's the plan. The question is do I have to make it before the mid-November feature freeze? Austin, what's your opinion? > So far as I can see, there simply is no list of what is enabled by -O or > -O2. I can make such a list if you want. > It's more than a simple on/off thing because the order matters. Hmm.... in which cases does it matter? Can you give an example? Janek

3 3

Re: [Msys2-users] Debugging undeterministic segfaults
by Gintautas Miliauskas 04 Nov '14

04 Nov '14

I have a suspicion that the segmentation faults are related to fork errors, which appear in logs from time to time. After a few builds fork() errors become very frequent, and segfaults seem to occur more often. I just ran the build (validate.sh) in a loop, and after a while got a bunch of segfaults in Makefile rules as basic as rm invocations in the initial "make clean", e.g.: "rm" -rf driver/split/dist driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist' failed make[1]: *** [clean_driver/split_dist] Segmentation fault Makefile:94: recipe for target 'maintainer-clean' failed Closing and reopening the msys2 console seems to help - for some time. On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly <mingw.android(a)gmail.com> wrote: > On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas > <gintautas.miliauskas(a)gmail.com> wrote: > > +ghc-devs > > > > Hi Ray, > > > > thanks for the feedback. ghc-stage1 is a native application, it is built > > using a host ghc and a mingw gcc bundled with the ghc distribution (in > order > > to keep Windows builds more predictable). The thing is, the same builds > > (using make) that were stable on cygwin seem to be crashing on msys2, > even > > though the (bundled) gcc used for the build is the same. It could be that > > msys2 is triggering a bug in ghc somehow, but it could be something > going on > > in msys2 itself. > > > > The tricky part is that the crashes are rare, one in thousands of ghc > > invocations within a make build, and I'm having trouble pinning one down > to > > investigate. I'll try some basic tracing first, but ideas for something > more > > sophisticated would be very helpful. > > Ah, ok. I skim read your initial email and applied totally incorrect > weighting to the "not very hard to reproduce" bit, apologies! > > It *should* be possible to setup post-mortem debugging using either Qt > Creator (Tools->Options->Debugger, tick "Use Qt Creator for > post-mortem debugging") or Dr. Mingw > (https://github.com/jrfonseca/drmingw) I briefly tested both options: > > Qt Creator: It seems there's a bug in its handling of the > -wincrashevent command line which I've just added a note about to the > MINGW-packages todo list since I'd find this feature more than very > useful: > https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md > > Dr Mingw: Launching the crashing executable from Windows Explorer, it > launches it and gives me useful information. > > Unfortunately, regardless of the debugger used, when invoking the > crashing executable from the mintty commandline, something inhibits > all post mortem debugging. I will ask the mingw-w64 guys if they know > what this is. I guess intrusive dialogs would be annoying, but I'd > like an env. var override for that I think. > > There is another possibility, and that's that bash is crashing, which > is an MSYS2 program. We do have a way of hooking into post-mortem > debugging there since Cygwin provided a way and we improved it. If you > check your msys2_shell.bat you'll see: > rem set > MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|<process-id> > > If you remove the rem and make sure the path is correct (it may have > rotted some since I last used it) then hopefully you'll get something > useful. To be really useful, you should rebuild two packages, > MSYS2-packages/{msys2-runtime,bash}/PKGBUILD with > options=('debug' '!strip') > and then install them. > > Finally, can anyone else confirm the problem? > > There may be some edge cases when e.g. PATH is around 1024 characters, > I've seen some hardcoded limits in the msys2-runtime (nee Cygwin) > code base for things like that. I'd advise cutting your Windows PATH > down to just the essentials. > > Cheers, > > Ray. > > > > > A PKGBUILD for ghc should be feasible, although the bootstrapping is a > bit > > tricky (some Haskell tools need to be preinstalled). I'm not sure how > useful > > it would be since for Windows there is already a nicely packaged native > > Haskell Platform installer. > > > > > > On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly <mingw.android(a)gmail.com> > > wrote: > >> > >> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas > >> <gintautas.miliauskas(a)gmail.com> wrote: > >> > Hello, > >> > > >> > I have been working on building GHC, the Glasgow Haskell Compiler, on > >> > Windows using msys2 [1]. We have been having some strange trouble with > >> > ghc > >> > segfaulting during the bootstrapping process (i.e., during make). The > >> > crashes are not very hard to reproduce, but they are not predictable > >> > either. > >> > This is almost certainly a bug in ghc itself and not with msys2 > >> > (although > >> > the crashes do not seem to occur in other environments), but I've been > >> > having some trouble pinning it down. > >> > > >> > >> Hi Gintuatas, > >> > >> Great. I spotted that MSYS2 was the recommended env. for GHC on > >> Windows, hopefully it will remain so! > >> > >> > What's a good way to debug such crashes? Is it possible to somehow > stop > >> > the > >> > ghc process when it segfaults and attach gdb, or to dump core somehow > >> > for > >> > later inspection? > >> > > >> > [1] > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > >> > > >> > Here's one example crash: > >> > > >> > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static > -H32m > >> > -O > >> > -Werror -Wall -H64m -O0 -this-package-key > ghc_4ugNArSu5ba0Z1uHXrbTlU > >> > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm > >> > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar > -icompiler/ghci > >> > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main > >> > -icompiler/nativeGen -icompiler/parser -icompiler/prelude > >> > -icompiler/profiling -icompiler/rename -icompiler/simplCore > >> > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn > >> > -icompiler/stranal -icompiler/typecheck -icompiler/types > >> > -icompiler/utils > >> > -icompiler/vectorise -icompiler/stage2/build > >> > -icompiler/stage2/build/autogen > >> > -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. > >> > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build > >> > -Icompiler/stage2 -optP-DGHCI -optP-include > >> > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key > >> > Win32_43THQMouBnk2wpnouztX1X -package-key array_GX4NwjS8xZkC2ZPtjgwhnz > >> > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key > >> > binpa_17GphrLqCXt1H1lm4Kse1p -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv > >> > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key > >> > direc_HU5aFxMIQNwGQFzisjuinu -package-key filep_34DFDFT9FVD9pRLLgh8IdQ > >> > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key > >> > hpc_1QTsfQSN40FHN9p3mydARY -package-key proce_7ZlAbRkwiRO8qgXx3NNP0G > >> > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key > >> > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key trans_5jw4w9yTgmZ89ByuixDAKP > >> > -Wall > >> > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 > >> > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing > >> > -O2 > >> > -fwarn-tabs -O -dcore-lint -no-user-package-db -rtsopts -odir > >> > compiler/stage2/build -hidir compiler/stage2/build -stubdir > >> > compiler/stage2/build -c compiler/basicTypes/UniqSupply.lhs -o > >> > compiler/stage2/build/UniqSupply.o > >> > > >> > compiler/ghc.mk:657: recipe for target > >> > 'compiler/stage2/build/UniqSupply.o' > >> > failed > >> > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation fault > >> > > >> > >> Well, it's pretty much the same story as with Linux. Build the > >> executable and as many libraries as you can with (something like) > >> "-ggdb -O0" then use gdb command line or some IDE of choice. > >> Personally I use Qt Creator (we have packages for this) as it can > >> debug external programs and, even though I don't dislike command > >> lines, I find debugging from them a bit too masochistic. > >> > >> Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is > >> it built with exactly? > >> > >> What would be involved in creating a PKGBUILD for ghc? We'd love to > >> have one, and it'd certainly make me a lot more inclined to dive in to > >> see what's going on if one existed already. > >> > >> Ray. > >> > >> > > >> > -- > >> > Gintautas Miliauskas > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > > >> > _______________________________________________ > >> > Msys2-users mailing list > >> > Msys2-users(a)lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/msys2-users > >> > > > > > > > > > > > -- > > Gintautas Miliauskas > -- Gintautas Miliauskas

1 0

Re: [Msys2-users] Debugging undeterministic segfaults
by Gintautas Miliauskas 04 Nov '14

04 Nov '14

+ghc-devs Hi Ray, thanks for the feedback. ghc-stage1 is a native application, it is built using a host ghc and a mingw gcc bundled with the ghc distribution (in order to keep Windows builds more predictable). The thing is, the same builds (using make) that were stable on cygwin seem to be crashing on msys2, even though the (bundled) gcc used for the build is the same. It could be that msys2 is triggering a bug in ghc somehow, but it could be something going on in msys2 itself. The tricky part is that the crashes are rare, one in thousands of ghc invocations within a make build, and I'm having trouble pinning one down to investigate. I'll try some basic tracing first, but ideas for something more sophisticated would be very helpful. A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit tricky (some Haskell tools need to be preinstalled). I'm not sure how useful it would be since for Windows there is already a nicely packaged native Haskell Platform installer. On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly <mingw.android(a)gmail.com> wrote: > On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas > <gintautas.miliauskas(a)gmail.com> wrote: > > Hello, > > > > I have been working on building GHC, the Glasgow Haskell Compiler, on > > Windows using msys2 [1]. We have been having some strange trouble with > ghc > > segfaulting during the bootstrapping process (i.e., during make). The > > crashes are not very hard to reproduce, but they are not predictable > either. > > This is almost certainly a bug in ghc itself and not with msys2 (although > > the crashes do not seem to occur in other environments), but I've been > > having some trouble pinning it down. > > > > Hi Gintuatas, > > Great. I spotted that MSYS2 was the recommended env. for GHC on > Windows, hopefully it will remain so! > > > What's a good way to debug such crashes? Is it possible to somehow stop > the > > ghc process when it segfaults and attach gdb, or to dump core somehow for > > later inspection? > > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > > > Here's one example crash: > > > > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m > -O > > -Werror -Wall -H64m -O0 -this-package-key ghc_4ugNArSu5ba0Z1uHXrbTlU > > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm > > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci > > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main > > -icompiler/nativeGen -icompiler/parser -icompiler/prelude > > -icompiler/profiling -icompiler/rename -icompiler/simplCore > > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn > > -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils > > -icompiler/vectorise -icompiler/stage2/build > -icompiler/stage2/build/autogen > > -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. > > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build > > -Icompiler/stage2 -optP-DGHCI -optP-include > > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key > > Win32_43THQMouBnk2wpnouztX1X -package-key array_GX4NwjS8xZkC2ZPtjgwhnz > > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key > > binpa_17GphrLqCXt1H1lm4Kse1p -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv > > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key > > direc_HU5aFxMIQNwGQFzisjuinu -package-key filep_34DFDFT9FVD9pRLLgh8IdQ > > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key > > hpc_1QTsfQSN40FHN9p3mydARY -package-key proce_7ZlAbRkwiRO8qgXx3NNP0G > > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key > > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key trans_5jw4w9yTgmZ89ByuixDAKP > -Wall > > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 > > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2 > > -fwarn-tabs -O -dcore-lint -no-user-package-db -rtsopts -odir > > compiler/stage2/build -hidir compiler/stage2/build -stubdir > > compiler/stage2/build -c compiler/basicTypes/UniqSupply.lhs -o > > compiler/stage2/build/UniqSupply.o > > > > compiler/ghc.mk:657: recipe for target > 'compiler/stage2/build/UniqSupply.o' > > failed > > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation fault > > > > Well, it's pretty much the same story as with Linux. Build the > executable and as many libraries as you can with (something like) > "-ggdb -O0" then use gdb command line or some IDE of choice. > Personally I use Qt Creator (we have packages for this) as it can > debug external programs and, even though I don't dislike command > lines, I find debugging from them a bit too masochistic. > > Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is > it built with exactly? > > What would be involved in creating a PKGBUILD for ghc? We'd love to > have one, and it'd certainly make me a lot more inclined to dive in to > see what's going on if one existed already. > > Ray. > > > > > -- > > Gintautas Miliauskas > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Msys2-users mailing list > > Msys2-users(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/msys2-users > > > -- Gintautas Miliauskas

2 4

Re: [commit: ghc] master: Add GHC.Prim.oneShot (c271e32)
by Jan Stolarek 03 Nov '14

03 Nov '14

Perhaps this should be documented in the User's Guide? Janek Dnia niedziela, 2 listopada 2014, git(a)git.haskell.org napisał: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/c271e32eac65ee95ba1aacc72ed1b24b5 >8ef17ad/ghc > > >--------------------------------------------------------------- > > commit c271e32eac65ee95ba1aacc72ed1b24b58ef17ad > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Sun Jan 26 11:36:23 2014 +0000 > > Add GHC.Prim.oneShot > > to allow the programer to explictitly set the oneShot flag. This helps > with #7994 and will be used in left folds. Also see > https://ghc.haskell.org/trac/ghc/wiki/OneShot > > This commit touches libraries/base/GHC/Event/Manager.hs (which used to > have a local definition of the name oneShot) to avoid a shadowing > error. > > Differential Revision: https://phabricator.haskell.org/D392 > > >--------------------------------------------------------------- > > c271e32eac65ee95ba1aacc72ed1b24b58ef17ad > compiler/basicTypes/MkId.lhs | 42 > ++++++++++++++++++++-- compiler/prelude/PrelNames.lhs | > 3 +- > libraries/base/GHC/Event/Manager.hs | 6 ++-- > libraries/ghc-prim/GHC/Magic.hs | 11 +++++- > testsuite/.gitignore | 1 + > .../should_compile => simplCore/prog003}/Makefile | 0 > testsuite/tests/simplCore/prog003/OneShot1.hs | 21 +++++++++++ > testsuite/tests/simplCore/prog003/OneShot2.hs | 24 +++++++++++++ > .../simplCore/prog003/simplCore.oneShot.stderr | 21 +++++++++++ > .../simplCore/prog003/simplCore.oneShot.stdout | 1 + > testsuite/tests/simplCore/prog003/test.T | 7 ++++ > 11 files changed, 130 insertions(+), 7 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc c271e32eac65ee95ba1aacc72ed1b24b58ef17ad > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

ghc panic during build
by Gintautas Miliauskas 03 Nov '14

03 Nov '14

Just got this during a build: "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty -package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint -fno-warn-deprecated-flags -fno-warn-tabs -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./GHC/TypeLits.hs -o libraries/base/dist-install/build/GHC/TypeLits.o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.9.20141031 for x86_64-unknown-mingw32): Ix{Int}.index: Index (2053) out of range ((0,10)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/build/GHC/TypeLits.o' failed I may have been building in a non-clean repository after a git pull though, could that have caused this? -- Gintautas Miliauskas

3 2

RE: thenIO removal
by David Feuer 03 Nov '14

03 Nov '14

Simon Peyton Jones wrote: > > It's not a big deal. > > You can probably replace both those bindIOName uses with bindMName (i.e > (>>=)), in TcRnDriver. That will just make GHCi generate code with uses of > overloaded (>>=) that must be evaluated, rather than calling bindIO > directly. It should work just fine, but it'll make everything a tiny bit > slower and more indirect. If it simplified the code a lot, then fine, but > it doesn't really. So I'm inclined to leave it. > That's fine; I don't know why my search didn't turn that up (perhaps it's referenced in some weird indirect way). If we're going to keep thenIO, we should surely define (*>) = (>>) = thenIO, right?

1 0

GHC Trac
by Simon Peyton Jones 03 Nov '14

03 Nov '14

Is it just me, or is the GHC Trac soul-destroyingly slow at the moment? IT takes minutes to load one page! Simon

3 2

GHC on Windows (extended/broad discussion)
by Austin Seipp 03 Nov '14

03 Nov '14

Gintautas, Tamar, Roman, (CC'ing those on https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce, and Kyrill, who has helped us out much in the past) Thank you all for all your help with Windows recently. I apologize for not responding to some of your concerns sooner in the recent threads about tarballs, etc. First off, all your contributions are extremely welcome - GHC has had many talented Windows hackers in days long past, but these days this number has dwindled! Anyone who has an interest in GHC on Windows is in a place to make a big impact and help us. All the work Gintautas has done for example, will dramatically improve the ghc-tarballs scenario. On that note: Gintautas, I will get D339 merged in ASAP, as soon as I test it and make a download mirror for you. Haskell.org has an awesome new CDN setup, and once I implement https://downloads.haskell.org, it will be easy to update tarballs and serve them to mass amounts of users. However, beyond that, we still need more done. First off, if you can help, we can help you! We can make lots of Windows build bots for people on demand, so if you're in desperate need of disk space or your computers are a bit slow, we can help accommodate. Right now, we have nightly builds with Gabor's[1] build system, and soon, we're working on a Phabricator integration, which should be great - and hopefully reduce the amount of breakage substantially. I also notice there is a ticket list of Windows issues[2], and that's fantastic. After a quick glance, a lot of these tickets are old, duplicates, or could possibly be closed or fixed easily. A good first task for any new contributor would be to go through this list, and try to replicate some of them! And you can always ask me - I can certainly help you navigate GHC a bit to get somewhere. But there are still other things. The Win32 package for example, is dreadfully lacking in maintainership. While we merge patches, it would be great to see a Windows developer spearhead and clean it up - we could even make some improvements in GHC itself based on this. This would be an excellent opportunity to make a good impact in the broader ecosystem! Finally, we desperately need someone to consult with when we're up a creek. Are certain patches OK for Windows? What's the best way to fix certain bugs, or implement certain features? I feel like often we try to think about this, but it's a bit lonely when nobody else is there to help! I'm not sure how to fix this, other than encouraging things like doing active code reviews and helping grind out some patches. But at the very minimum, I'd just like to talk with you about things perhaps! So in summary - the work so far is grand, and we want to help you do more! And I'm sure everyone can help - there's always so much to do and so little time, we need to encourage it all we can. As Simon says: Upward and Onward! [1] http://haskell.inf.elte.hu/builders/ [2] https://ghc.haskell.org/trac/ghc/query?status=!closed&os=Windows&desc=1&ord… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 18

Problem with installing "primitive" on Windows/i686
by Gintautas Miliauskas 03 Nov '14

03 Nov '14

Installation of Alex in the msys2 i686 instructions is broken, more details in https://ghc.haskell.org/trac/ghc/ticket/9712. Before I spend more time on this, maybe someone knows off the bat what's going on? $ cabal install alex Resolving dependencies... Downloading primitive-0.5.4.0... Configuring primitive-0.5.4.0... Failed to install primitive-0.5.4.0 Build log ( C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log ): [1 of 1] Compiling Main ( C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs, C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o ) Linking C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe ... Configuring primitive-0.5.4.0... setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing dependency on a foreign library: * Missing (or bad) header file: primitive-memops.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. If the header file does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. -- Gintautas Miliauskas

2 1