Windows support #140

Closed hasufell closed 1 year ago

In GitLab by @maerwald on May 15, 2021, 07:11

Motivation

Users have frequently requested windows support of ghcup. Recent discussions have shown that the Haskell Foundation is pushing for installers that support all 3 platforms (linux, mac, windows) consistently.

We believe that ghcup with its unix philosophy model and built around the principles of rustup is the right approach for fixing these concerns.

Implementation plan

make the codebase build on windows (see WIP PR)
manage MSys2
create an installer like rustup (powershell wrapper)

Specification

Interface

Windows will have the same interface as unix, including command line options and directory structure.

MSys2

TODO

Installer

TODO

In GitLab by @trac-gershomb on May 15, 2021, 08:22

I think that key steps are 1) to have ghcup download and run the latest msys2 installer (not sure where the canonical source for this would be) and 2) to have ghcup then run cabal user-config -a to augment the cabal config file with the "magic lines" similar to:

extra-prog-path: C:\Program Files\Haskell Platform\8.0.2\msys\usr\bin extra-lib-dirs: C:\Program Files\Haskell Platform\8.0.2\mingw\lib extra-include-dirs: C:\Program Files\Haskell Platform\8.0.2\mingw\include

If the user-config mechanism isn't great, ghcup certainly can modify the config file itself by any mechanism it pleases.

Outside of that, there's just "get it running on windows at all" afaik.

In GitLab by @maerwald on May 16, 2021, 04:07

@randen would be good if you can add your summary/insights here

In GitLab by @maerwald on May 19, 2021, 05:27

ghcup now builds on windows... there are some rough edges and I need do adjust some details about GHC installation as to not require ./configure on windows

https://stackoverflow.com/a/47380501 seems also relevant... I'm still not sure how exactly we want to manage msys2. As a component that's updatable? Which distribution do we need to fetch?

In GitLab by @trac-gershomb on May 19, 2021, 07:48

See the comment in "Note" here: https://community.chocolatey.org/packages/msys2/ Even chocolatey does not update msys2 itself. msys uses pacman to self-update. (Sadly, many windows users of ghc, including myself, are fairly msys2 illiterate and not great about doing these things ourselves, but it is nonetheless The Way, from what I see).

I can't speak to the correct distribution and definitive source for it, however...

In GitLab by @maerwald on May 19, 2021, 20:18

For symlinks to work, we need developer mode... is there a way to detect whether developer mode is active?

In GitLab by @trac-gershomb on May 20, 2021, 24:01

stackoverflow suggests checking a registry key, which sounds right: https://stackoverflow.com/questions/41231586/how-to-detect-if-developer-mode-is-active-on-windows-10

not sure the easiest way to do that from haskell.

In GitLab by @randen on May 20, 2021, 24:16

The official site for MSYS2 is https://www.msys2.org/ and their github repo also has built distros in their "releases", matching what is on msys2.org.

My understanding is that we will have ghcup download and install MSYS2.

From what I can glean, it seems projects like ours which need MSYS2 for their Windows-flavor (e.g., rust, python), use it only for building rather than needing to distribute. Or, they bundle only a subset (e.g., rtools for build R packages; git for Windows). Other projects where it is needed at the end user side, they just ask them to install it and provide the link. Rust seems to just include a few gnu build tools (a nerfed gcc, ld, etc.). Sometimes they solve the problem by making an MSYS2 pacman distributed of their product (e.g., Rust has a variant like that).

Ruby DevKit

However, Ruby does what Haskell Platform used to do (and with better flexiblity): one variant of their installer (the "DevKit") bundles a full MSYS2. They also have a slimmer Ruby-language-only, but it is not the recommended choice for first install, especially given that Rails requires the DevKit flavor, with all the linux-y tools, and that the DevKit is also needed to build certain gems and/or some of the linux-y libraries certain gems link.

The DevKit has an executable with a few commands, one is to "activate" or "enable" MSYS2, which adds its location to the PATH. It might (or could, in the future) do more than than, haven't checked.

They allow sharing of MSYS2 with other Ruby versions by the user manually moving the msys64 directory up one level, to the common folder of all the installed Ruby versions, and apparently, their toolchain that "activates" MSYS2 knows to look there first (or puts both on the PATH, with the common place first?), then to the version-specific subdirectory. So, nothing automatic for sharing but there is a path.

I would need to check more, but they also might add a few "batteries" to the MSYS2 distribution, as part of their bundle, to get a few more packages.

The Ruby project seems to have no qualms about the size of the DevKit, especially considering that it is done only once. They have recommendations about when to install to a new location, but presumably, anytime after the initial install, users can use the Ruby-only installer (rather than the DevKit flavor), couple with their above mentioned support for a (manual) way of having a shared MSYS2 install.

If we download MSYS2 during ghcup installation, we would need to use a static URL for this.

Maybe I misunderstood, but if not, then perhaps we should consider bundling MSYS2, rather than download, which resolves the URL issue and the 32-bit issue, but does make a much bigger download, at least for the initial installation.

32-bit MSYS2

Is 32-bit ghc currently supported for Windows? If so, we would need the 32-bit MSYS2. They no longer build a 32-bit MSYS2; their last build for 32-bit was their 2020-05-17 release. This would probably not be a real issue for our purposes, as the build tools needed are typically very common (on linux), relatively stable, well-established command-line utilities.

Updating MSYS2

gershomb, you raise a very good point about upgrading MSYS2: ghcup should install it once, and then never again. The note on the msys2 package at chocolatey.org says that MSYS2 will not be installed again or updated; that is up to the end user via pacman, after the initial install. Once pacman has modified the MSYS2 installation, the user wouldn't want ghcup to install something on top of that.

In GitLab by @randen on May 20, 2021, 24:28

I haven't used it but there is the venerable and maintained System.Win32.Registry from the Win32 package.

Windows 7/8 support

What is the oldest version of Windows that ghc supports? If Windows 7 and/or 8 are still on the list, the developer mode of Windows 10 mechanism would need to be conditional. Also, the method of symlinking might not work the same on Windows 7/8 as on Windows 10.

In GitLab by @maerwald on May 20, 2021, 01:53

Progress report:

Installation on its own seems to be working: https://imgur.com/a/rbZIWJh
I've created a #haskell-ghcup channel on Libera IRC (the successor of freenode)

In GitLab by @maerwald on May 20, 2021, 02:56

WRT MSys2

So my idea would be this:

the installation of MSys2 would not be handled by the ghcup executable, but the ghcup bootstrapper (on linux, this is the bootstrap-haskell shell script... on windows, this would be an executable that launches an interactive powershell installation like rustup... I'd have to look into how they do that)
the bootstrapper would install MSys2 once and optionally
the bootstrapper would ask whether MSys2 be added to PATH or whether cabal.config should be adjusted

Whether the boostrapper should bundle MSys2 or download it... I have no idea. I'm not sure how to implement either currently, so that would need investigation.

WRT Symlinks and Win7/8 support

I'm not sure how feasible it is to rely on symlinks, but ghcup is designed around it and it would be quite annoying to have windows-specific workarounds. I'm also not sure how such a workaround would look like... just copying would require changes to how SET versions are discovered. Using a shell wapper script would be another option.

In GitLab by @trac-gershomb on May 20, 2021, 03:41

Note that cabal itself has code to generate powershell that performs a download, which can be cribbed from (https://github.com/haskell/cabal/blob/00a2351789a460700a2567eb5ecc42cca0af913f/cabal-install/src/Distribution/Client/HttpUtils.hs#L597) . As you note, I'm expecting that the bootstrap-haskell shell script would need to be ported to powershell in general anyway. Which seems like a key task, and also somewhat of a PITA though perhaps randy or tamar might be more familiar with how to do it.

If we're not confident in a stable upstream url, its easy of course to provide hosting for a msys2 to download from haskell.org servers.

In GitLab by @maerwald on May 21, 2021, 23:42

So I believe now that the codebase of the current PR is in a usable state for starting with msys2 story, powershell installer and deciding on how to proceed with symlinks.

All bare tool installations work so far.

In GitLab by @maerwald on May 23, 2021, 19:20

My experience with msys2 so far:

I installed MSys2 from http://repo.msys2.org/distrib/x86_64/msys2-base-x86_64-20210419.tar.xz into ~/.ghcup/msys64
I ran msys2_shell.cmd as the documentation outlines
I ran pacman -Syuu
I tried to run update-core as the documentation says, but it doesn't exist
I ran pacman -Sy, pacman -Suu and pacman -S mingw-w64-x86_64-toolchain
I restarted the powershell
I ran cabal user-config -a "extra-prog-path: $HOME\.ghcup\bin, $HOME\AppData\Roaming\cabal\bin, $HOME\.ghcup\msys64\usr\bin, $HOME\.ghcup\msys64\mingw64\bin" -a "extra-include-dirs: $HOME\.ghcup\msys64\mingw64\include" -a "extra-lib-dirs: $HOME\.ghcup\msys64\mingw64\lib" -f init
I tried cabal build on a project... and it picked the ghc shipped toolchain in ~/.ghcup/ghc/8.10.4/mingw, then failed with obscure hsc2hs errors
so I removed ~/.ghcup/ghc/8.10.4/mingw and tried again
now cabal says it cannot detect a mingw toolchain
I tried adding $HOME\.ghcup\msys64\mingw64\bin and $HOME\.ghcup\msys64\usr\bin directly to PATH and it didn't work either
I tried in powershell, mingw shell, nothing

So it doesn't seem any of the instructions are working.

In GitLab by @randen on May 24, 2021, 02:24

This is just random speculation but it might be possible that some command (e.g., hsc2hs) is being launched/forked with a command line that is "too long", as the older/legacy Windows APIs had some limits we have hit in the past (e.g., given the long paths of cabal v2's hashed name structure, the command line can become much longer than with v1). If it is ok with you, I could take a look at this failure, if the ghcup branch you are working on is available for me to see.

I can also just try the commands you listed, independent of the ghcup part, so let me try at least as much as I can without ghcup right now.

Also, could be a mismatch between the environment and assumptions that cabal uses when executing in Windows OS versus the configuration you applied above with the user-config augmentations. I believe cabal would want/need Windows OS-style paths. That is, not the MSYS2 style, e.g., root with drives specified as "/C/". Cabal needs them in Windows-style, e.g., like "C:" and maybe cabal-install is ambidextrous about which was the slashes go (I can't recall; I need to check--but of course, MSYS2 only likes unix/linux-style path seperators). Or was the cabal.exe executed from the PowerShell?

In GitLab by @maerwald on May 24, 2021, 06:13

@randen it seems to work when invoked like cabal build -w ~/.ghcup/ghc/8.10.4/bin/ghc.exe as opposed to cabal build -w ghc-8.10.4... which suggests it's a problem with symlinks

In GitLab by @randen on May 25, 2021, 01:00

Again, maybe some useless speculation, but I sort of recall that ghc looks about its executable location, on Windows platforms, to find its gcc (and maybe some other executables as well?) so maybe it is resolving the symlink location as its "home"? If this is the case, perhaps there is another API it should use to resolve where it actually lives? Again, I may be totally wrong in any or all of this.

However, I did try it just now, simulating the ghcup functionality (as I understand it) by using "mklink" (n.b., for Windows 7, needs to be done as an administrator, or at least with a particular privilege enabled on the user id) from every executable in ghc's bin directory to %HOME%\.ghcup\bin. I also mklink-ed cabal into this location as well. Then restricted my PATH to C:\Windows\system32;C:\Windows and the my .ghcup\bin directory. With this setup, I was able to build an example project that uses the network package (a configure-style package).

Earlier, this is how I configured my cabal config file, using the CMD command prompt (not PowerShell in this case), copied from your similar command above but with path separators in "Windows-style" and environment variables in Windows syntax:

cabal user-config -a "extra-prog-path: %HOME%\.ghcup\bin, %HOME%\AppData\Roaming\cabal\bin, %HOME%\.ghcup\msys64\usr\bin, %HOME%\.ghcup\msys64\mingw64\bin" -a "extra-include-dirs: %HOME%\.ghcup\msys64\mingw64\include" -a "extra-lib-dirs: %HOME%\.ghcup\msys64\mingw64\lib" -f init

The actual cabal commands I issued to build this example project (the source, server.hs, I copied/pasted from the network hackage page; the test.cabal is just the simplest you could get by with, with build-depends of network, bytestring, and base):

cabal v2-install --dependencies-only --enable-documentation --haddock-hyperlink-source --haddock-executables --haddock-html

cabal v2-configure

cabal v2-build

In GitLab by @maerwald on May 25, 2021, 01:02

@randen did you try to build bzlib?

In GitLab by @randen on May 25, 2021, 02:34

I have just now tried this (building an executable which depends on the bzlib package), and it worked for me in the setup as described above. I used the example bzip2.hs (as main.hs) given in the examples folder of bzlib, with a simple .cabal file.

However, I have ghc 9.0.1 and cabal 3.4.0.0 installed (and I don't yet have ghcup to make it easy to switch these :) ), so I did a get to include the bzlib package locally, then hacked its .cabal file to be ok with ghc's base version, and added a "cabal.project" file in my project's directory (this file has the "packages:" directive that listed the local directory where I hacked the bzlib.cabal file, so I get that one instead of one from hackage).

It all seems to build fine, including the .c files of bzlib, and the resulting executable works as expected.

In GitLab by @maerwald on May 25, 2021, 14:39

extra-prog-path does not work very well: https://github.com/haskell/cabal/issues/7404

In GitLab by @maerwald on May 25, 2021, 14:40

However, I have ghc 9.0.1 and cabal 3.4.0.0 installed

It is only reproducable with 8.10.4.

In GitLab by @maerwald on May 25, 2021, 21:56

Also not clear to me which environment we want: https://www.msys2.org/docs/environments/

In GitLab by @randen on May 26, 2021, 24:09

Regarding the question of which of the MSYS2-provided "environments" to use, it should match what ghc is built with so everything links without issues or needing additional runtime DLLs. We might need to keep track of more than one MSYS2 variant, and map those as appropriate to the GHC variant that the user has made the "current" one.

Last I knew (which has been a couple years, sorry), ghc on Windows was built with against MINGW64 and MINGW32 (when ghc supported 32-bit Windows, but is this no longer the case?). Those are the MSYS2 environments which depend on the msvcrt flavor of C runtime.

If LLVM is a supported toolchain for ghc on Windows, and the user installed that flavor of ghc, then an LLVM flavor of MSYS2 would be appropriate.

If ghc supports the ucrt flavor of C runtime (which is Windows 10-specific), any ghc-supported Windows versions earlier than Windows 10, apparently, do not have this, so users might need to have/get this installed, too (or we say only Windows 10 is supported by such a ghc build).

In GitLab by @maerwald on May 26, 2021, 03:56

Also: I can't build a working ghcup binary anymore. I have one here, but that one doesn't include the latest commits. But now... whatever commit I try to build, even the same one from the linked binary (you can see the commit via --version)... ghcup will output nothing.

I looked for hours whether it's the code, the toolchain or the phase of the moon. Building with 9.0.1 instead didn't help. Building with stack failed due to the same hsc2hs errors, funnily.

So I'm stuck.

In GitLab by @maerwald on May 26, 2021, 20:16

As can be seen here... I only get exit status 0 and output when I run via strace... now how is that?

hasuf@DESKTOP-G57OLGB MINGW64 ~/ghcup-hs
$ cabal build -w /c/ghcup/ghc/9.0.1/bin/ghc.exe
Build profile: -w ghc-9.0.1 -O1
In order, the following will be built (use -v for more details):
 - ghcup-0.1.14.2 (exe:ghcup) (configuration changed)
Configuring executable 'ghcup' for ghcup-0.1.14.2..
Warning: The package has an extraneous version range for a dependency on an
internal library: ghcup >=0 && ==0.1.14.2, ghcup >=0 && ==0.1.14.2, ghcup >=0
&& ==0.1.14.2. This version range includes the current package but isn't
needed as the current package's library will always be used.
Preprocessing executable 'ghcup' for ghcup-0.1.14.2..
Building executable 'ghcup' for ghcup-0.1.14.2..
[1 of 1] Compiling Main             ( app\ghcup\Main.hs, C:\Users\hasuf\ghcup-hs\dist-newstyle\build\x86_64-windows\ghc-9.0.1\ghcup-0.1.14.2\x\ghcup\build\ghcup\ghcup-tmp\Main.o ) [flags changed]
Linking C:\Users\hasuf\ghcup-hs\dist-newstyle\build\x86_64-windows\ghc-9.0.1\ghcup-0.1.14.2\x\ghcup\build\ghcup\ghcup.exe ...

hasuf@DESKTOP-G57OLGB MINGW64 ~/ghcup-hs
$ cp 'C:\Users\hasuf\ghcup-hs\dist-newstyle\build\x86_64-windows\ghc-9.0.1\ghcup-0.1.14.2\x\ghcup\build\ghcup\ghcup.exe' .

hasuf@DESKTOP-G57OLGB MINGW64 ~/ghcup-hs
$ ./ghcup.exe --help
Usage: ghcup.exe [(-v|--verbose) | --no-verbose] [(-c|--cache) | --no-cache]
                 [--verify | (-n|--no-verify)] COMMAND

Available options:
  -v,--verbose             Enable verbosity (default: disabled)
  -c,--cache               Cache downloads in ~/.ghcup/cache (default: disabled)
  -n,--no-verify           Disable tarball checksum verification (default:
                           enabled)
  --keep <always|errors|never>
                           Keep build directories? (default: errors)
  --downloader <curl|wget> Downloader to use (default: curl)
  -h,--help                Show this help text
  --version                Show version
  --numeric-version        Show the numeric version (for use in scripts)

Main commands:
  install                  Install or update GHC/cabal
  set                      Set currently active GHC/cabal version
  rm                       Remove a GHC/cabal version
  list                     Show available GHCs and other tools
  upgrade                  Upgrade ghcup
  compile                  Compile a tool from source

Other commands:
  debug-info               Show debug info
  tool-requirements        Show the requirements for ghc/cabal
  changelog                Find/show changelog

Discussion:
  ghcup installs the Glasgow Haskell Compiler from the official
  release channels, enabling you to easily switch between different
  versions. It maintains a self-contained ~/.ghcup directory.

ENV variables:
  * TMPDIR: where ghcup does the work (unpacking, building, ...)
  * GHCUP_INSTALL_BASE_PREFIX: the base of ghcup (default: $HOME)
  * GHCUP_USE_XDG_DIRS: set to anything to use XDG style directories

Report bugs at <https://gitlab.haskell.org/haskell/ghcup-hs/issues>

hasuf@DESKTOP-G57OLGB MINGW64 ~/ghcup-hs
$ ./ghcup.exe --version
The GHCup Haskell installer, version v0.1.14.1-25-g6002c5c

hasuf@DESKTOP-G57OLGB MINGW64 ~/ghcup-hs
$ ./ghcup.exe list

hasuf@DESKTOP-G57OLGB MINGW64 ~/ghcup-hs
$ strace ./ghcup.exe list
--- Process 9832 created
--- Process 9832 loaded C:\Windows\System32\ntdll.dll at 00007fff02e70000
--- Process 9832 loaded C:\Windows\System32\kernel32.dll at 00007fff01a20000
--- Process 9832 loaded C:\Windows\System32\KernelBase.dll at 00007fff00630000
--- Process 9832 loaded C:\Windows\System32\advapi32.dll at 00007fff01f40000
--- Process 9832 loaded C:\Windows\System32\msvcrt.dll at 00007fff02600000
--- Process 9832 thread 9524 created
--- Process 9832 loaded C:\Windows\System32\sechost.dll at 00007fff01ea0000
--- Process 9832 loaded C:\Windows\System32\rpcrt4.dll at 00007fff02320000
--- Process 9832 thread 11240 created
--- Process 9832 thread 9020 created
--- Process 9832 loaded C:\Windows\System32\gdi32.dll at 00007fff02700000
--- Process 9832 loaded C:\Windows\System32\dbghelp.dll at 00007ffef5920000
--- Process 9832 loaded C:\Windows\System32\win32u.dll at 00007fff00e00000
--- Process 9832 loaded C:\Windows\System32\gdi32full.dll at 00007fff00900000
--- Process 9832 loaded C:\Windows\System32\ucrtbase.dll at 00007fff00a10000
--- Process 9832 loaded C:\Windows\System32\msvcp_win.dll at 00007fff00e30000
--- Process 9832 loaded C:\Windows\System32\user32.dll at 00007fff02100000
--- Process 9832 loaded C:\Windows\System32\ole32.dll at 00007fff01c60000
--- Process 9832 loaded C:\Windows\System32\combase.dll at 00007fff016c0000
--- Process 9832 loaded C:\Windows\System32\shell32.dll at 00007fff00f70000
--- Process 9832 loaded C:\Windows\System32\shlwapi.dll at 00007fff026a0000
--- Process 9832 loaded C:\Windows\System32\ws2_32.dll at 00007fff02530000
--- Process 9832 loaded C:\Windows\System32\winmm.dll at 00007ffeed840000
--- Process 9832 loaded C:\Windows\System32\dbgcore.dll at 00007ffef68f0000
--- Process 9832 loaded C:\Windows\System32\imm32.dll at 00007fff020d0000
--- Process 9832 loaded C:\Windows\System32\SHCore.dll at 00007fff01d90000
--- Process 9832 thread 992 created
--- Process 9832 thread 5372 created
--- Process 9832 loaded C:\Windows\System32\windows.storage.dll at 00007ffefe6f0000
--- Process 9832 loaded C:\Windows\System32\wldp.dll at 00007ffefff50000
--- Process 9832 loaded C:\Windows\System32\profapi.dll at 00007fff004f0000
--- Process 9832 thread 7868 created
--- Process 10248 created
--- Process 10248 loaded C:\Windows\System32\ntdll.dll at 00007fff02e70000
--- Process 10248 loaded C:\Windows\System32\kernel32.dll at 00007fff01a20000
--- Process 10248 loaded C:\Windows\System32\KernelBase.dll at 00007fff00630000
--- Process 10276 created
--- Process 10276 loaded C:\Windows\System32\ntdll.dll at 00007fff02e70000
--- Process 10276 loaded C:\Windows\System32\kernel32.dll at 00007fff01a20000
--- Process 10276 loaded C:\Windows\System32\KernelBase.dll at 00007fff00630000
--- Process 10276 loaded C:\Windows\System32\msvcp_win.dll at 00007fff00e30000
--- Process 10276 loaded C:\Windows\System32\ucrtbase.dll at 00007fff00a10000
--- Process 10276 thread 6316 created
--- Process 10276 thread 3892 created
--- Process 10276 loaded C:\Windows\System32\SHCore.dll at 00007fff01d90000
--- Process 10276 loaded C:\Windows\System32\msvcrt.dll at 00007fff02600000
--- Process 10276 loaded C:\Windows\System32\combase.dll at 00007fff016c0000
--- Process 10276 loaded C:\Windows\System32\rpcrt4.dll at 00007fff02320000
--- Process 10276 thread 1804 created
--- Process 10276 loaded C:\Windows\System32\advapi32.dll at 00007fff01f40000
--- Process 10276 loaded C:\Windows\System32\sechost.dll at 00007fff01ea0000
--- Process 10276 thread 4052 created
--- Process 10276 thread 6316 exited with status 0x0
--- Process 10276 thread 3892 exited with status 0x0
--- Process 10276 thread 1804 exited with status 0x0
--- Process 10276 thread 4344 exited with status 0x0
--- Process 10276 loaded C:\Windows\System32\user32.dll at 00007fff02100000
--- Process 10276 loaded C:\Windows\System32\win32u.dll at 00007fff00e00000
--- Process 10276 loaded C:\Windows\System32\gdi32.dll at 00007fff02700000
--- Process 10276 loaded C:\Windows\System32\gdi32full.dll at 00007fff00900000
--- Process 10276 thread 6880 created
--- Process 10276 thread 9288 c   Tool  Version        Tags                      Notes
✗  ghc   7.10.3         base-4.8.2.0
✗  ghc   8.0.2          base-4.9.1.0
✗  ghc   8.2.2          base-4.10.1.0
✗  ghc   8.4.1          base-4.11.0.0
✗  ghc   8.4.2          base-4.11.1.0
✗  ghc   8.4.3          base-4.11.1.0
✗  ghc   8.4.4          base-4.11.1.0
✗  ghc   8.6.1          base-4.12.0.0
✗  ghc   8.6.2          base-4.12.0.0
✗  ghc   8.6.3          base-4.12.0.0
✗  ghc   8.6.4          base-4.12.0.0
✗  ghc   8.6.5          base-4.12.0.0
✗  ghc   8.8.1          base-4.13.0.0
✗  ghc   8.8.2          base-4.13.0.0
✗  ghc   8.8.3          base-4.13.0.0
✗  ghc   8.8.4          base-4.13.0.0
✗  ghc   8.10.1         base-4.14.0.0
✗  ghc   8.10.2         base-4.14.1.0
✗  ghc   8.10.3         base-4.14.1.0
✗  ghc   8.10.4         recommended,base-4.14.1.0
✗  ghc   9.0.1          latest,base-4.15.0.0
✗  ghc   9.2.0.20210422 prerelease,base-4.16.0.0
✗  cabal 2.4.1.0
✗  cabal 3.0.0.0
✗  cabal 3.2.0.0
✗  cabal 3.4.0.0        latest,recommended
✗  hls   1.1.0          latest,recommended
✗  stack 2.5.1
✗  stack 2.7.1          latest,recommended
✗  ghcup 0.1.14.1       latest,recommended
reated
--- Process 10276 loaded C:\Windows\System32\imm32.dll at 00007fff020d0000
--- Process 10276 loaded C:\Windows\System32\shell32.dll at 00007fff00f70000
--- Process 10276 loaded C:\Windows\System32\uxtheme.dll at 00007ffefe010000
--- Process 10276 thread 8388 created
--- Process 10248 loaded C:\Windows\System32\ws2_32.dll at 00007fff02530000
--- Process 10248 loaded C:\Windows\System32\rpcrt4.dll at 00007fff02320000
--- Process 10248 thread 11052 created
--- Process 10248 thread 9308 created
--- Process 10248 loaded C:\Windows\System32\crypt32.dll at 00007fff00bf0000
--- Process 10248 loaded C:\Windows\System32\ucrtbase.dll at 00007fff00a10000
--- Process 10248 thread 8584 created
--- Process 10248 loaded C:\Windows\System32\cryptsp.dll at 00007ffeffea0000
--- Process 10248 loaded C:\Windows\System32\secur32.dll at 00007ffefa660000
--- Process 10248 loaded C:\Windows\System32\sspicli.dll at 00007fff00470000
--- Process 10248 loaded C:\Windows\System32\mswsock.dll at 00007ffeffcc0000
--- Process 10248 thread 7368 created
--- Process 10248 loaded C:\Windows\System32\kernel.appcore.dll at 00007ffefe4f0000
--- Process 10248 loaded C:\Windows\System32\msvcrt.dll at 00007fff02600000
--- Process 10248 loaded C:\Windows\System32\dnsapi.dll at 00007ffeff9f0000
--- Process 10248 loaded C:\Windows\System32\IPHLPAPI.DLL at 00007ffeff9b0000
--- Process 10248 loaded C:\Windows\System32\nsi.dll at 00007fff02e20000
--- Process 10248 loaded C:\Windows\System32\rasadhlp.dll at 00007ffef84a0000
--- Process 10248 loaded C:\Windows\System32\FWPUCLNT.DLL at 00007ffef6730000
--- Process 10248 loaded C:\Windows\System32\bcrypt.dll at 00007fff005b0000
--- Process 10248 thread 7368 exited with status 0x0
--- Process 10248 thread 8856 created
--- Process 10248 loaded C:\Windows\System32\schannel.dll at 00007ffeff580000
--- Process 10248 loaded C:\Windows\System32\mskeyprotect.dll at 00007ffef0640000
--- Process 10248 loaded C:\Windows\System32\ntasn1.dll at 00007ffefff80000
--- Process 10248 loaded C:\Windows\System32\ncrypt.dll at 00007ffefffc0000
--- Process 10248 loaded C:\Windows\System32\sechost.dll at 00007fff01ea0000
--- Process 10248 loaded C:\Windows\System32\ncryptsslp.dll at 00007ffef0b20000
--- Process 10248 loaded C:\Windows\System32\bcryptprimitives.dll at 00007fff00b70000
--- Process 10248 unloaded DLL at 00007ffefa660000
--- Process 10248 thread 8856 exited with status 0x0
--- Process 10248 unloaded DLL at 00007ffef6730000
--- Process 10248 thread 8584 exited with status 0x0
--- Process 10248 thread 9308 exited with status 0x0
--- Process 10248 thread 11052 exited with status 0x0
--- Process 10248 exited with status 0x0
--- Process 10276 thread 4052 exited with status 0x0
--- Process 10276 thread 8388 exited with status 0x0
--- Process 10276 thread 6880 exited with status 0x0
--- Process 10276 exited with status 0x0
--- Process 9832 thread 7868 exited with status 0x0
--- Process 9832 thread 9524 exited with status 0x0
--- Process 9832 thread 11240 exited with status 0x0
--- Process 9832 thread 992 exited with status 0x0
--- Process 9832 thread 5372 exited with status 0x0
--- Process 9832 thread 9020 exited with status 0x0
--- Process 9832 exited with status 0x0

In GitLab by @amesgen on May 26, 2021, 21:35

I built the windows-support branch via this Github Actions config, and the resulting binary (see "Artifacts") seems to be able to run .\ghcup.exe list just fine.

In GitLab by @randen on May 27, 2021, 24:26

Maybe I'm seeing this wrong, but it seems you are building from one of the MSYS2-style shell with bash. I may not have mentioned that in my experiment a few comments above, was built entirely from the Windows DOS CMD shell, not a MING64/MSYS bash shell. In the past, I noticed that the Haskell executable, hptool, that we built for the Haskell Platform must be built from the Windows command line, not any MSYS2-type of shell. The problem manifested as path construction problems and sometime strange failures, deep in haddock or some cabal generated command line to ghc.

Anyway, am I looking at your log above correctly? If so, have you tried the entire build from a CMD prompt instead of an MSYS2 bash shell?

I can try this, too, if the windows-support branch is the one to try. Please let me know if this would help you.

In GitLab by @AndreasK on May 27, 2021, 03:44

For what it's worth I was able to run and build this also (within a msys based shell). But I haven't tried in cmd.exe/powershell.

In GitLab by @maerwald on May 27, 2021, 03:50

I think I managed... here's the prototype installer as an executable: https://downloads.haskell.org/~ghcup/tmp/bootstrap-haskell-2.exe

It currently needs developer mode enabled, because it uses symlinks... I'll change that in a bit.

For the record: I get defunct executables if I start an msys2-mingw64 shell and build ghcup there.

In GitLab by @maerwald on May 29, 2021, 06:12

I got rid of the symlinking stuff (using shim executables now) and fixed a lot of bugs:

In GitLab by @cdsmith on May 31, 2021, 08:56

@maerwald was looking for testers earlier, and I installed bootstrap-haskell-7.exe from the link above. Windows Defender (virus scan) has now decided that the software contains malware called "Trojan:Win32/Wacatac.B!ml" I initially thought the message that malware was detected was a false positive just because the executable isn't signed, but this is a fairly specific description. Can we be certain that this wasn't built on a compromised machine or somehow included malware (maybe indirectly) in the executable?

In GitLab by @maerwald on May 31, 2021, 14:48

Can we be certain that this wasn't built on a compromised machine or somehow included malware (maybe indirectly) in the executable?

It was built from https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/windows-support/bootstrap-haskell.ps1 with https://www.powershellgallery.com/packages/ISESteroids/2.7.1.7 on my personal VM.

In GitLab by @randen on Jun 2, 2021, 24:03

There are some sites which allow you to upload your executable for scanning by multiple antiviral programs. In the past, we have uploaded to Microsoft's Windows Defender Securty Intelligence for a scan of the Haskell Platform executable. Should we try that? We can also try an aggregator of scanners (but I forgot which of those aggregators someone suggested would be good to use, so I don't have one at hand to recommend).

In GitLab by @maerwald on Jun 2, 2021, 24:45

I ordered an open source signing certificate, that's supposed to work on executables. But when I tried to activate I got errors and am stuck with tech support.

In GitLab by @maerwald on Jun 3, 2021, 02:27

https://adamtheautomator.com/ps1-to-exe/#Features_Comparison says that ISE Steroids is known to have malware false positive @cdsmith

Edit: PowerShell Pro Tools too https://github.com/ironmansoftware/issues/issues/203

In GitLab by @randen on Jun 3, 2021, 07:39

To further verify our suspicions, I submitted bootstrap-haskell-7.exe (from the link given in an early comment) to the Micrsoft Security Intelligence website and the "final determination" is "Not malware" with their action being "We have removed the detection."

In GitLab by @maerwald on Jun 3, 2021, 21:05

I frequently have issues with compiled binaries and I haven't been able to pin-point the origin of this problem: https://i.imgur.com/VpTLLPW.png

In GitLab by @maerwald on Jun 5, 2021, 19:10

mentioned in issue ghc/ghc#19945

In GitLab by @maerwald on Jun 5, 2021, 23:30

Relevant: https://gitlab.haskell.org/ghc/ghc/-/issues/19945#note_357034

In GitLab by @maerwald on Jun 6, 2021, 04:27

Done. Release candidate in progress.

In GitLab by @pepeiborra on Oct 4, 2021, 04:04

I tried setting up a Windows VM to build HLS, and used ghcup to install ghc. Cannot get past from the network package:

Using the Win10 image for VirtualBox from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

In GitLab by @trac-gershomb on Oct 4, 2021, 04:12

This doesn't look like the exact error, but it may be related to a windows configure regression with cabal 3.6 (a release is in the works). Try with 3.4 perhaps?

In GitLab by @pepeiborra on Oct 4, 2021, 04:37

@trac-gershomb thank you!!! Cabal 3.4 worked just fine

In GitLab by @maerwald on Oct 4, 2021, 05:17

Hmm, that's concerning.

In GitLab by @jneira on Oct 4, 2021, 20:38

yeah :worried: , the fix will be included in the incoming 3.6.2 release

https://github.com/haskell/cabal/issues/7671

original issue report: https://github.com/haskell/cabal/issues/7649

haskell / ghcup-hs