On 9/28/2014 11:16 PM, Gintautas Miliauskas wrote:
However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on Windows than 4.8.3.
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? Don't think so. I think msys2 mingw64/mingw32 supply more or less the same builds as thread-posix+seh/thread-posix+dwarf builds supplied by 'mingw-builds' (they also make another combinations).
One of windows' specific problem of gcc 4.9.1 was that DLL built using it turned out to be broken, such that OS refused to load it. And that was not a binutils' problem, switching compiler only to gcc 4.8.3 fixed things for me. But that was not related to using GHC. And there are chances gcc 4.9.1 is not a culprit itself and simply exposed some bug sitting elsewhere. I didn't investigate the problem thoroughly.
'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...).
Sounds good. Should we switch to this using this package instead of the rubenvb build? Perhaps. At least, I didn't have *any* problems with it.
Cheers, Kyra