Building ghc on Windows with msys2

[Gintautas Miliauskas]

> 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?

> '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/).

Sounds good. Should we switch to this using this package instead of the
rubenvb build?

> 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.

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 <kyrab at mail.ru> wrote:

> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140928/c443c4cb/attachment.html>