Windows build gotchas

David Macek david.macek.0 at gmail.com
Thu Jan 8 17:00:35 UTC 2015


On 1. 1. 2015 19:01, Martin Foster wrote:
> Hello all,
> 
> I've been spending some of my winter break trying my hand at compiling GHC, with a mind to hopefully contributing down the line.
> 
> I've got it working, but I ran into a few things along the way that I figure might be worth fixing and/or documenting. In the approximate order I encountered them:
> 
>   * The first pacman mirror on the list bundled with MSYS2 is down, with the result that every download pacman makes takes ~10sec longer than it should. It downloads a lot, so that really adds up - but it's easy to fix, just "pacman -Sy pacman-mirrors" before doing anything else with it. Is that worth mentioning on the wiki? I was thinking a line on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows could be helpful.

This is an unfortunate, but temporary situation. The next MSYS2 installer will come with updated mirror lists. I don't know what's the policy on including this kind of information on the wiki.

>   * That page mentions "If you see errors related to fork(), try closing and reopening the shell" - I've determined that you can reliably avoid that problem by following the instructions at http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/#iii-updating-packages, ie by running "pacman --needed -S bash pacman msys2-runtime", then closing & re-opening the MSYS shell, before you tell pacman to install the GHC prerequisite packages.

This may be true for the GHC guide, but AFAIK if you decide to install other packages, you may still encounter fork errors. The installation process is taken care of by updating bash, pacman and the runtime separately, but subsequent invocations of MSYS2 programs could still fail due to newly installed MSYS2 libraries (if any).

>   *  And finally, the big one: cabal and/or ghc-pkg put some files outside the MSYS root directory, and caused me no end of trouble in doing so...
> 
> I made a bit of a mess at one point, and tried to fix it by starting over completely from scratch. I expected uninstalling & reinstalling MSYS to achieve this (it deletes its root directory when you uninstall it), but that left me with a huge pile of errors when I tried to run "cabal install -j --prefix=/usr/local alex happy", of the form "Could not find module `...': There are files missing in the `...' package".
> 
> I noticed that the cabal output made reference to "C:\Users\Martin\AppData\Roaming\cabal\", so tried moving that out of the way, but it only made the problem worse. I did figure it out eventually: in addition to that directory, "%APPDATA%\cabal", there were also files left over in "%APPDATA%\ghc". Once I removed that directory as well, things started working again - but it took me a lot of time & frustration to get there.
> 
> I'm not entirely sure, but I think the copy of Cabal I already had from installing the Platform may also have been storing files in those directories, in which case this process completely mangled them - which isn't great.
> 
> It seems to me that, ideally, the "build GHC inside MSYS" procedure would keep itself entirely inside the MSYS directory structure: if it were wholly self-contained, you'd know where everything is, and it couldn't break anything outside. As far as I can tell, the only breach is those two directories courtesy of Cabal, so I didn't think it would be too difficult - but none of the things I've tried (the --package-db cabal flag, a custom cabal --config-file, setting the GHC_PACKAGE_PATH environment variable, maybe some others I've forgotten) had the desired effect. Is it possible? Is it even a good idea?
> 
> If that's just how it has to be, I feel like there should be an obvious note somewhere for the sake of the next person to trip over it.

I had problems with this also, so I definitely support mentioning these two on the wiki. If we ever get to having a ghc package for MSYS2, it will use $HOME instead of $APPDATA, but that won't actually help with the problem of MSYS2 re-install not cleaning everything the build left behind.

-- 
David Macek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4234 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150108/78120cdf/attachment.bin>


More information about the ghc-devs mailing list