Opened 11 months ago

Last modified 5 months ago

#9218 patch task

Upgrade the version of MinGW shipped with GHC

Reported by: komadori Owned by: gintas
Priority: normal Milestone: 7.12.1
Component: Build System Version: 7.8.2
Keywords: Cc: niklasl, gintas, hamish
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking: #9215
Related Tickets: #3390 Differential Revisions: Phab:D339

Description

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

Download all attachments as: .zip

Change History (19)

comment:1 Changed 11 months ago by komadori

The MinGW binaries used by the GHC build are stored in a git repository (http://git.haskell.org/ghc-tarballs.git/tree). Note that the ia32 binaries use the original MinGW and the amd64 binaries use the MinGW-w64 fork. kyra suggests (http://www.haskell.org/pipermail/ghc-devs/2014-June/005172.html) switching to use MinGW-w64 for both platforms, but this apparently requires some patches to GHC.

comment:2 Changed 11 months 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!

Simon

comment:3 Changed 11 months ago by niklasl

  • Cc niklasl added

comment:4 Changed 10 months 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 10 months ago by hvr

See also this ghc-devs thread as a whole.

Last edited 10 months ago by hvr (previous) (diff)

comment:6 Changed 8 months ago by gintas

  • Cc gintas added

comment:7 Changed 8 months ago by hamish

  • Cc hamish added

comment:8 Changed 8 months ago by gintas

  • Owner changed from komadori to gintas

I am looking into this.

comment:9 Changed 8 months ago by komadori

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

comment:10 Changed 8 months ago by gintas

  • Differential Revisions set to Phab:D339

comment:11 Changed 8 months ago by gintas

  • Status changed from new to patch

comment:12 Changed 7 months 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 7 months ago by awson (previous) (diff)

Changed 7 months ago by awson

comment:13 Changed 7 months ago by gintas

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

comment:14 Changed 7 months 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 7 months 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 7 months ago by gintas

I've run validate.sh 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 download.haskell.org in case the files on sourceforge are removed.

comment:17 Changed 7 months ago by thomie

  • Blocking 9215 added

comment:18 Changed 5 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

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.

Note: See TracTickets for help on using tickets.