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
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
