Building ghc on Windows with msys2

[Simon Marlow]

On 27/09/2014 22:04, Gintautas Miliauskas wrote:

> 8. A broader question: what general approach to ghc on Windows shall we
> take? The prebuilt packages currently provided by ghc-tarballs are also
> covered by msys2's package manager. Why not offload that pain to msys2
> then? The advantage here is less maintenance (and automatic upgrades of
> the toolchain), the disadvantage is that the distribution becomes less
> stable and msys2 updates could break ghc builds more easily. I think it
> would make sense to be consistent with the Linux builds; we don't bundle
> compilers with those. In that sense msys2 would be like another
> distribution. Of course, we need to also consider if msys2 can be
> trusted to stick around and stay up to date in the long run. It looks
> like a relatively new project, so there's some risk.
>
> 9. If I understand correctly, one other thing to consider before
> dropping ghc-tarballs is that Windows ghc still needs GCC utilities
> (like cpp) to function properly, and so we need to have a prepackaged
> bundle of binary GCC utilities (and maybe hardcoded paths? not sure) to
> make that work. On the other hand, a custom-built ghc should work just
> fine in the msys2 environment which does provide cpp et al., and the
> additional GCC bundles would perhaps best be owned by, for example, the
> Haskell Platform project rather than be part of core ghc?
>
> 10. Following the idea in (8), I tried to build ghc using the mingw gcc
> provided by msys2 instead of the one in ghc-tarballs. It was a bit
> weird. I had to hack configure.ac <http://configure.ac> to disable use
> of ghc-tarballs and try to use system tools. How about a configure
> option to enable/disable use of ghc-tarballs? I also ran into some weird
> issues, for example, the system ld and nm would not get detected by the
> configure script correctly. They were found when I explicitly set LD=ld
> and NM=nm. Weird. Will look into that later. Other than that, there were
> no major problems, except...
>
> 11. A build with the host gcc failed. I think the cause is that it is
> too new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The
> build of the currently checked in GMP (libraries/integer-gmp) fails
> because a utility used in the build process segfaults. I tried upgrading
> gmp from 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the
> ghc-specific patch used for 5.0.3 no longer applies (is it still
> necessary?). Oh brother. One of the advantages of tracking msys2's gcc
> would be that we would notice such breakage earlier. Shall I open an issue?

We created ghc-tarballs for stability reasons.  In the past, some 
versions of mingw were broken, so we wanted to ensure that everyone 
building GHC on Windows was using the same gcc, and that a given build 
of GHC will ship with a predictable gcc, rather than grabbing whatever 
is installed.

I think it's pretty important that GHC can be installed independently of 
mingw.  That dependency used to be huge source of pain when we had it.

Windows is unlike Linux, in that on Linux it's easy to install a working 
gcc.  Many distributions already ship it, and even when they don't, the 
package manager makes it easy to add gcc as a dependency of GHC so it 
gets installed automatically.

Cheers,
Simon