Opened 3 years ago

Closed 19 months ago

Last modified 18 months ago

#9218 closed task (fixed)

Upgrade the version of MinGW shipped with GHC

Reported by: komadori Owned by: gintas
Priority: normal Milestone: 8.0.1
Component: Build System Version: 7.8.2
Keywords: Cc: niklasl, gintas, hamish, RyanGlScott
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: #9014 Blocking: #9215
Related Tickets: #3390 #10705 #10726 Differential Rev(s): Phab:D339
Wiki Page:


The Windows binary distribution of GHC incorporates a version of MinGW which has not been updated for several releases and is now out-of-date. It should be upgraded. The previous time this was done appears to correlate with ticket #3390.

Attachments (1)

Linker_c.patch (31.8 KB) - added by awson 2 years ago.

Download all attachments as: .zip

Change History (30)

comment:1 Changed 3 years ago by komadori

The MinGW binaries used by the GHC build are stored in a git repository ( Note that the ia32 binaries use the original MinGW and the amd64 binaries use the MinGW-w64 fork. kyra suggests ( switching to use MinGW-w64 for both platforms, but this apparently requires some patches to GHC.

comment:2 Changed 3 years ago by simonpj

Robin, as my email to you (who I is komadori, comment 1) says, we'd be thrilled if felt like leading or partnering with eg. Kyra to do this. Thank you!


comment:3 Changed 3 years ago by niklasl

Cc: niklasl added

comment:4 Changed 3 years ago by RyanGlScott

GHC's out-of-date version of MinGW-w64 currently prevents me from developing a Windows version of Bluetooth libraries for Haskell. GHC's version of MinGW-w64 (2.0) doesn't pack the necessary Bluetooth structs correctly, whereas the current version (3.1) does. Attempting to link against the most recent MinGW-w64's libraries results in problems as well, since the Bluetooth-related headers have changed substantially (e.g., the NS_BTH macro was introduced), and compilation often results in this issue (usually with cabal repl).

In addition, the Bluetooth functionality is not available on MinGW, only on MinGW-w64, so switching to minGW-w64 for both Windows architectures would allow me to develop for 32-bit Windows as well.

comment:5 Changed 3 years ago by hvr

See also this ghc-devs thread as a whole.

Last edited 3 years ago by hvr (previous) (diff)

comment:6 Changed 2 years ago by gintas

Cc: gintas added

comment:7 Changed 2 years ago by hamish

Cc: hamish added

comment:8 Changed 2 years ago by gintas

Owner: changed from komadori to gintas

I am looking into this.

comment:9 Changed 2 years ago by komadori

That's good :-). I've had no time.

comment:10 Changed 2 years ago by gintas

Differential Rev(s): Phab:D339

comment:11 Changed 2 years ago by gintas

Status: newpatch

comment:12 Changed 2 years ago by awson

Here I propose my patchset for rts/Linker.c (against current HEAD).

It intersects with Gintas' one, but does a bit more (COMDAT support for gcc 4.9.x) and does some things in a more straightforward manner -- mostly in handling name decoration things.

What's going on with name decoration? Well, original code have some crufty and ad-hocish paths related mostly to very old mingw gcc/binutils/runtime combinations. Now mingw-w64 offers pretty uniform and MS-compatible decoration scheme across its tools and runtime.

The scheme is pretty straightforward: on 32 bit objects symbols are exported with underscore prepended (and @ + stack size suffix appended for stdcall functions), on 64 bits no underscore is prepended and no suffix is appended because we have no stdcall convention on 64 bits.

On top of that __imp_ prefix is further prepended for dllimported symbols.

Mingw-w64 runtime is conformant to MS declaring all win32 symbols dllimported, while old mingw is not and this is why 32-bit cases differ so much.

I commented on this extensively in #7097 and #2283.

My patch reflects these considerations and also unifies a bunch of RTS imports between 32 and 64 bit cases.

Last edited 2 years ago by awson (previous) (diff)

Changed 2 years ago by awson

Attachment: Linker_c.patch added

comment:13 Changed 2 years ago by gintas

awson, thanks for the patch! I'll get to testing it right away.

comment:14 Changed 2 years ago by awson

Perhaps I should mention this patch solves swprintf problem a bit differently from your approach (I've already commented on this).

Also I didn't test it on 32 bits for quite a long time (several months or so).

comment:15 Changed 2 years ago by gintas

Yep, I'm aware of _CRT_NON_CONFORMING_SWPRINTFS. I'll try testing on 32-bit, will let you know how that goes. Thanks again.

comment:16 Changed 2 years ago by gintas

I've run on Windows with x86_64 and i686 toolchains, both are looking reasonable with kyra's patch. There are some failures, but most of them are also there with the baseline.

I think the only remaining blocker is the mirror location for mingw-w64 packages on in case the files on sourceforge are removed.

comment:17 Changed 2 years ago by thomie

Blocking: 9215 added

comment:18 Changed 2 years ago by thoughtpolice


Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:19 Changed 21 months ago by thomie

Blocked By: 9014 added

comment:20 Changed 21 months ago by RyanGlScott

Cc: RyanGlScott added

comment:21 Changed 19 months ago by lukexi

Would be awesome to get this merged! This causes tons of noise on Windows.

comment:22 Changed 19 months ago by thomie

Status update. Nobody is working on this at the moment. GHC sees very little Windows volunteers in general.

The unfinished patch in Phab:D339 does (too) many things:

  • linker changes needed to go with that, mostly from awson's patch in comment:12
  • change the provider of the 32bit and 64bit packages from rubenvb to mingw-builds. By default this results in much larger downloads (2x for 64bit, 5x for 32bit), which means #9014 should be fixed first.
  • remove all Perl dependencies, which means it's waiting for #9832.
  • downloads mingw during ./configure step, instead of via explicit git clone ...ghc-tarballs.git.

comment:23 Changed 19 months ago by Phyx-

I've started splitting this up to get it in:

•downloads mingw during ./configure step, instead of via explicit git clone ...ghc-tarballs.git.

This is now done in #10705

•change the provider of the ​32bit and ​64bit packages from rubenvb to mingw-builds. By default this results in much ​larger downloads (2x for 64bit, 5x for 32bit), which means #9014 should be fixed first.

Any particular reason why this was done? Was there anything missing from the rubenvb builds?

Last edited 19 months ago by Phyx- (previous) (diff)

comment:24 Changed 19 months ago by Phyx-

comment:25 Changed 19 months ago by thomie

awson: your patch is now in, maybe you could give it a quick glance and a thumbs up? Please either comment here or by creating an account on Phabricator.

comment:26 Changed 19 months ago by thomie

awson: do you have any idea what that test failure in ghci/prog003 is about?

comment:27 Changed 19 months ago by Ben Gamari <ben@…>

In 7b211b4/ghc:

Upgrade GCC to 5.2.0 for Windows x86 and x86_64

This patch does a few things

- Moved GHC x86 to MinGW-w64 (Using Awson's patch)
- Moves Both GHCs to MSYS2 toolchains
- Completely removes the dependencies on the git tarball repo
  - Downloads only the required tarball for the architecture for
    which we are building
  - Downloads the perl tarball is missing as well
  - Fixed a few bugs in the linker to fix tests on Windows

The links currently point to and GitHub, it might be
more desirable to mirror them on as with the previous patch

For more details on what the MSYS2 packages I include see #10726
(Awson's comment). but it should contain all we need
and no python or fortran, which makes the uncompressed tar a 1-2
hundreds mb smaller.

The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
this is a problem since
when compiling with -shared the produced dll now has a dependency on
To solve this the flag `-static-libgcc` is now being used for all GCC
calls on windows.

Test Plan:
./validate was ran both on x86 and x86_64 windows and compared against
the baseline.

A few test were failing due to Ld no longer being noisy. These were

The changes to the configure script *should* be validated by the build
bots for the other platforms before landing

Reviewers: simonmar, awson, bgamari, austin, thomie

Reviewed By: thomie

Subscribers: #ghc_windows_task_force, thomie, awson

Differential Revision:

GHC Trac Issues: #10726, #9014, #9218, #10435

comment:28 Changed 19 months ago by thomie

Resolution: fixed
Status: patchclosed

Let's close this one as well.

comment:29 Changed 18 months ago by thoughtpolice


Milestone renamed

Note: See TracTickets for help on using tickets.