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).
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.
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.
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!
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.
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:
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.:
but there’s no perfect solution. Not all packages make use of 