Hi Simon, Andrey

> 3. After this step, starting a shell failed altogether with "c:/msys64/mingw64_shell.bat is
> not recognised as an internal or external command". And sure enough, there is no such file.
> Presumably it existed in step 1. So perhaps step 2 deleted it?
> [...]
> 4. As you mention, I then tried msys2_shell.cmd. It worked -- with a noticeable delay of 5
> seconds or so.

I've also just got a new Win10 laptop and had the same issue with missing mingw64_shell.bat during msys2 install. I solved it by creating mingw64.bat with the following contents:

msys2_shell.cmd -mingw64 -mintty

I deleted all old shortcuts and use this script instead. Everything seems to work fine -- can build GHC.

Yes this is correct, the msys2 team has decided to "streamline" all their different batch files to launch msys from 4 to 1, hence the only remaining one is msys2_shell.cmd which accepts arguments of which shell to open and using which console host.

Unfortunately this is done via their upgrade-core script and doesn't know how to remove the installer shortcuts, so you end up with dead shortcuts.

> 1. I just left the machine for 10-15 mins and lo! the shell windows opened up. It just took a loooong time.
>
> At this point, starting a new shell no longer took a long time. It all seemed to be working.

First launch should be finishing setting up the environment so will take slightly longer, but shouldn't have taken that long. Could this be AV related?

I always add an exception to the AV (or the build in windows defender) for the msys2 folder to prevent it from scanning files continuously. Especially

building GHC this can slow things down considerably depending on the AV.

> 2. I then ran pacman -Syuu as instructed on the installation page: https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
>
> The log of what happened is below. There are numerous failures involving Cygwin, which I do not have installed, at least not so far as I know. I do not know if these failures matter.

These instructions are basically telling it to upgrade the world. They are however a bit wrong, https://github.com/Alexpux/MSYS2-packages/issues/373

msys2 is derived from Cygwin so it inherits much of the problems of Cygwin. The msys2 runtime is the Cygwin runtime with patches added which is why the errors mention Cygwin.

The issue is that the msys2-runtime has been upgraded by "pacman -Syuu" at which point a new "Cygwin" dll has been downloaded. However all Cygwin/msys2 runtimes share the same

address space and thus you can't have multiple versions of the same runtime loaded at once. This is why subsequent calls to anything relying on the msys2 runtime will fail with a weird

fork error. The solution is to just close all open msys2 window and re-open.

Our own instructions page https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows breaks this down in a few steps to avoid this issue. 1) first update the packages and 2) only after that update the msys-core files.

But you will still need to restart the shell.

> * should I worry about all those install errs

No they're perfectly fine and expected. I would however re-run the pacman -Syu to make sure all packages were updated, now that the runtime has been updated already it shouldn't be updated again

and you shouldn't see any fork errors.

> * how can I debug what's happening with

> that long delay

If it's only startup and not executing of other commands or bash completion then my bet would be AV software. If bash completion is slow or commands like ls as well

you may be hitting a long standing issue some computers have in which the domain controller is being hit for every invocation of commands, causing a slowdown https://github.com/Alexpux/MSYS2-packages/issues/138 , Solution 2 from https://gist.github.com/k-takata/9b8d143f0f3fef5abdab seems to fix it for most people.

* Should I nuke the start menu shortcuts that

the msys64 installer so carefully installed

in favour of msys2_shell.cmd?

Yes, these are now dead. you need to use msys2_shell.cmd but also pass it -mingw64 so it knows what shell to start. mintty is supposed to be the default, but in case that changes you can also pass it -mintty as well to be sure it doesn't change.

I am working on a script to automate this setup, hopefully that would make it easier next time!

Cheers,

Tamar