Building ghc on Windows with msys2

[kyra]

On 9/28/2014 1:04 AM, Gintautas Miliauskas wrote:
> 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?
I believe this is not a segfault, it's a GHC RTS' dynamic linker barfing 
it can't handle duplicated symbols. Since 4.9 gcc (on Windows at least) 
started to generate .linkonce section for external symbols. I have a 
patch for this and I successfully built GHC HEAD with the most fresh 
stock msys2 mingw64 components.

However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on 
Windows than 4.8.3. 'Mingw-builds' project (which is now a part of 
mingw-w64 project and is considered to be an "official" mingw-w64 gcc 
distribution and is maintained by a man close to Msys2 project) has very 
nice and complete build of 4.8.3 (64-bit build, for example, is here: 
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/).

I also urge to not use "msys2's gcc" phrase because it's possible to 
install gcc which uses msys2 runtime and generates binaries which use 
msys2 runtime, but it is absolutely wrong thing. What do we want in fact 
is to use mingw64 (x86_64-w64-mingw32) or mingw32 (i686-w64-mingw32) 
toolchains based on and targeting mingw-w64 runtime.

Cheers,
Kyra