One option to fix this is to try using LLD for linking. Unfortunately
#16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Replying to [ticket:16084 bgamari]: the msys2 `gcc` does not support `-fuse-ld=lld`. LLD won't magically help here. Latest improvements by Martin Storsjö (mstorsjo) have made LLD able to link some mingw **gcc**-generated code, but, alas, when assembling **GHC**-generated assembly, mingw **gas** produces (I believe this is a sort of "optimisation") non-standard relocations, which LLD is unable to deal with (honestly, I haven't checked if this is still the case, but it was definitely so a year or two ago). For quite a bit of time I have a GHC port which works flawlessly against native Windows SDK and uses clang in MSVC mode and MS or LLD linker. After recent LLD improvements by mstorsjo I've decided to try a less intrusive approach — use clang in mingw mode and LLD linker. That required quite a bit of work and I finally managed to produce stage2 GHC executable, which appeared to be severely broken — it is unable to do anything. TL;DR the current state of affairs is that `lld` **can't** serve as a drop-in replacement for `ld` not only when GNU binutils toolchain is used, but even when `clang` is used as an assembler. Perhaps, the latter might work against mingw SDK built using LLVM tools (e.g. https://github.com/mstorsjo/llvm-mingw), but I never tried this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16084#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler