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/
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
Hmm, that sounds like an argument against trusting msys2 to provide a sane
mingw gcc compiler... Bummer. What kind of bugs did you have in mind?
projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/
mingw-builds/4.8.3/threads-posix/seh/).
Sounds good. Should we switch to this using this package instead of the
rubenvb build?
based on and targeting mingw-w64 runtime.
Yes, I know (now, after wasting some time on that...). The suggestion was
exactly to warn the user if such a type of gcc is detected, because that's
almost never what you want.
On Sun, Sep 28, 2014 at 9:08 AM, 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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Gintautas Miliauskas