[ANNOUNCE] GHCup 0.1.15-rc2 Windows pre-release

hasufell · June 6, 2021, 2:11pm

Thanks to many people helping me out on Windows, MSys2 etc.

This is a pre-release, so especially on Windows, you may run into issues.

Changes

Add windows support wrt #130
Add stack support
Warn when /tmp doesn’t have 5GB or more of disk space
Allow to compile GHC from git repo wrt #126
Allow to set custom ghc version when running ‘ghcup compile ghc’ wrt #136

How to test the pre-release

On Windows

Download https://downloads.haskell.org/ghcup/windows-bootstrap/bootstrap-haskell-1.0.1.exe and run it as user, then follow the on-screen instructions.

Note: the executable isn’t signed yet, but windows defender should not get triggered.

On Linux/Mac/FreeBSD

ghcup -s https://www.haskell.org/ghcup/data/ghcup-0.0.4-rc2.yaml upgrade

Where to report problems

https://kiwiirc.com/nextclient/irc.libera.chat/#haskell-ghcup
https://gitlab.haskell.org/haskell/ghcup-hs/-/issues
email: hasufell at posteo dot de

sclv · June 6, 2021, 2:54pm

Thanks hausefell! I want to point out for those that haven’t been following the development details that this work has been very careful and thorough and in the process helped stress-test GHC on windows full stop, including some tricky longstanding issues with linking and msys that have been problems in the past for all ways to install GHC on windows – so this is not just providing a nice new clean path for windows installation, but also helping to solidify the platform more directly as a whole (and as I’m following along, I see the process on freebsd is leading to some improvements as well).

hasufell · June 6, 2021, 3:17pm

Right, here are some of the tickets that happened in the process:

tomjaguarpaw · June 6, 2021, 3:32pm

ghcup running on Windows is fantastic! Great stuff!

hasufell · June 6, 2021, 5:03pm

As a side not: there’s no tui on windows, because brick depends on unix. If anyone has an idea how to create something similar under windows… speak up.

jaror · June 6, 2021, 5:55pm

I know only ansi-terminal but that is way lower level. Making brick and vty work on windows is also overdue in my opinion (this is not meant as complaint to the maintainers). Maybe that can also be guided, for lack of a better word, by the foundation. I don’t think there are fundamental problems why vty cannot be ported to windows.

f-a · June 6, 2021, 6:20pm

ansi-terminal-game is not properly TUI itself (rather, does more than you would like, I suspect).

I have written it with cross compatibility in mind and it works; I can decouple the needed features if it is useful. Windows support and Windows testing is always a pain in the proverbial butt, Haskell community lacks Win users!

hasufell · June 11, 2021, 11:23pm

The release is final now at 0.1.15.1

On windows, run:

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; Invoke-WebRequest -UseBasicParsing https://www.haskell.org/ghcup/sh/bootstrap-haskell.ps1 | Invoke-Expression

wiz · August 28, 2021, 3:16pm

What’s the Windows story for msys-backed dependencies? Should one expect everything working out of the box, or some assembly required?

jneira · August 29, 2021, 9:17am

hi! the installation changes the cabal config to add msys paths:

extra-include-dirs: D:\ghcup\msys64\mingw64\include
extra-lib-dirs: D:\ghcup\msys64\mingw64\lib
extra-prog-path: D:\ghcup\bin,
                 C:\Users\user\AppData\Roaming\cabal\bin,
                 D:\ghcup\msys64\usr\bin,
                 D:\ghcup\msys64\mingw64\bin

So the idea is msys libs should be available out of the box

hasufell · August 29, 2021, 1:23pm

Additionally, there is a deskop shortcut to drop into the ghcup provided msys2 shell, where you can run pacman -S package etc.

Generally, you want to run cabal via cmd/powershell though.

There’s also a hyperlink desktop shortcut to: https://www.msys2.org/docs/package-management/

Those things should get you started.

wiz · September 1, 2021, 7:50pm

I’ve got msys2 packages working and now stuck with linking problems.

With default options I have a bunch of “multiple definition” errors:

Linking C:\src\orboros\dist-newstyle\build\x86_64-windows\ghc-8.10.6\orboros-0.1.0.0\x\orboros\opt\build\orboros\orboros.exe ...
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: d000000.o:(.idata$2+0x0): multiple definition of `_head_libstdc___6_dll'; C://ghcup//ghc//8.10.6//mingw//bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/libstdc++.dll.a(d000000.o):(.idata$2+0x0): first defined here
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: d000001.o:(.idata$5+0x0): multiple definition of `__imp__ZTVN10__cxxabiv117__class_type_infoE'; C://ghcup//ghc//8.10.6//mingw//bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/libstdc++.dll.a(d006211.o):(.idata$5+0x0): first defined here   
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: d000001.o:(.idata$6+0x0): multiple definition of `__nm__ZTVN10__cxxabiv117__class_type_infoE'; C://ghcup//ghc//8.10.6//mingw//bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/libstdc++.dll.a(d006211.o):(.idata$6+0x0): first defined here    
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: d000002.o:(.idata$5+0x0): multiple definition of `__imp__ZTVN10__cxxabiv120__si_class_type_infoE'; C://ghcup//ghc//8.10.6//mingw//bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/libstdc++.dll.a(d006216.o):(.idata$5+0x0): first defined here
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: d000002.o:(.idata$6+0x0): multiple definition of `__nm__ZTVN10__cxxabiv120__si_class_type_infoE'; C://ghcup//ghc//8.10.6//mingw//bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/libstdc++.dll.a(d006216.o):(.idata$6+0x0): first defined here 
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: d000003.o:(.idata$7+0x0): multiple definition of `libstdc___6_dll_iname'; C://ghcup//ghc//8.10.6//mingw//bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/libstdc++.dll.a(d006570.o):(.idata$7+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)

With static executable that changes into a few "cannot find"s:

Linking C:\src\orboros\dist-newstyle\build\x86_64-windows\ghc-8.10.6\orboros-0.1.0.0\x\orboros\opt\build\orboros\orboros.exe ...
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: cannot find -lstdc++-6
C://ghcup//ghc//8.10.6//mingw//bin/ld.exe: cannot find -lgcc_s_seh-1
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)

(And building with ghcup-installed stack using system-ghc spams some packaging error for every dependency out there. But that’s not the thing I want to focus on right now.)

Deleting that lib/gcc/x86_64-w64-mingw32/9.2.0/libstdc++.dll.a helps with linking the executable, but that breaks the build for some packages with C++ deps inside them (namely VulkanMemoryAllocator).

Building, then deleting that .dll.a gives me an executable, but it’s a horrible UX.
And I suspect there’s something fishy going on around those C++ bits since it crashes where it worked on my previous stack setup.

hasufell · September 1, 2021, 9:40pm

It appears you are trying to build https://gitlab.com/dpwiz/orboros

I was able to make it build with adding this to cabal.project:

package orboros
    ghc-options: -optl-Wl,--allow-multiple-definition

I’m not sure where the error comes from, but GHC ships with its own small mingw64 toolchain. Maybe that conflicts with the unpacked msys2 distribution? Notice that your global ~/.cabal/config should have the following entries:

extra-include-dirs: C:\ghcup\msys64\mingw64\include
extra-lib-dirs: C:\ghcup\msys64\mingw64\lib
extra-prog-path: C:\ghcup\bin,
                 C:\Users\hasuf\AppData\Roaming\cabal\bin,
                 C:\ghcup\msys64\usr\bin,
                 C:\ghcup\msys64\mingw64\bin

The extra-include-dirs and extra-lib-dirs actually break ghcup compilation itself but there’s no perfect solution. Not all packages make use of pkg-config, so extra-prog-path isn’t enough.

So one way might be to remove extra-include-dirs and extra-lib-dirs from ~/.cabal/config and add it back manually only to those packages that need it in cabal.project, e.g.:

package OpenAL
    extra-include-dirs: C:\ghcup\msys64\mingw64\include
    extra-lib-dirs: C:\ghcup\msys64\mingw64\lib

Also, are you building from cmd/powershell?

wiz · September 2, 2021, 8:59am

Thanks! I’ll check that.

(BTW, is this an appropriate place for such a discussion or should we move elsewhere?)

hasufell · September 2, 2021, 11:09am

This might be related: https://gitlab.haskell.org/ghc/ghc/-/issues/20010

That btw might be due to the fact that your set GHC version doesn’t correspond to the stackage LTS. system-ghc just picks whatever ghc.exe is in PATH.

For this type of integration to work better, I created https://github.com/commercialhaskell/stack/pull/5585
But the stack team hasn’t replied to it.

wiz · September 3, 2021, 1:13pm

It works now

This might be related: https://gitlab.haskell.org/ghc/ghc/-/issues/20010

I ended up using ghc-options: -optl"-Wl,-Bstatic,-lstdc++,-lgcc_s,-Bdynamic" to the executable target.