But this causes linking errors. Has anyone gotten other linkers to work on Windows? Ideally I’d love a config line I could drop into stack/cabal config files but at this point I’d be ecstatic about any information.
I’d guess that especially method 2 and 3 may trigger windows defender, because ghc invocations run via two binaries. So the distinction may be relevant.
I noticed that occasionally the slowdown is significantly worse for the haskell-language-server startup in large projects. Either way, creating exceptions can effectively circumvent the problem.
At least the codegen and RTS linker memory allocator shall be fixed, but even then I’m not sure things will go smooth.
I have a pretty hugely modified GHC (closed source ATM), which uses LLD (and can also use MS Link, but this is much slower), but it targets Visual_C/UCRT runtime.
I plan to check if my codegen and RTS linker memory allocator fixes allow using lld with mingw-w64 runtime (perhaps this would also dictate switching from gcc to clang, I don’t know).
I will open the fixes if they work, but I don’t know when I will have the energy to do it.
I do think getting @awson’s stuff open source is the best way to improve Windows support. I am quite sure we could wrangle all the patches of everything (including LLVM) in Nixpkgs very quickly for better cross compilation out of the box before any upstreaming happens. Of course, once it does, the native out-of-the-box situation will improve too.