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
On 9/28/2014 1:04 AM, Gintautas Miliauskas wrote: 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%20Wi...). 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