Opened 15 months ago

Closed 3 weeks ago

#9218 closed task (fixed)

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

Download all attachments as: .zip

Change History (29)

comment:1 Changed 15 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 15 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 14 months ago by niklasl

  • Cc niklasl added

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

See also this ghc-devs thread as a whole.

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

comment:6 Changed 11 months ago by gintas

  • Cc gintas added

comment:7 Changed 11 months ago by hamish

  • Cc hamish added

comment:8 Changed 11 months ago by gintas

  • Owner changed from komadori to gintas

I am looking into this.

comment:9 Changed 11 months ago by komadori

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

comment:10 Changed 11 months ago by gintas

  • Differential Revisions set to Phab:D339

comment:11 Changed 11 months ago by gintas

  • Status changed from new to patch

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

Changed 10 months ago by awson

comment:13 Changed 10 months ago by gintas

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

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

  • Blocking 9215 added

comment:18 Changed 8 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.

comment:19 Changed 3 months ago by thomie

  • Blocked By 9014 added

comment:20 Changed 3 months ago by RyanGlScott

  • Cc RyanGlScott added

comment:21 Changed 6 weeks ago by lukexi

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

comment:22 Changed 6 weeks 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 5 weeks 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 5 weeks ago by Phyx- (previous) (diff)

comment:24 Changed 5 weeks ago by Phyx-

comment:25 Changed 4 weeks ago by thomie

awson: your patch is now in https://phabricator.haskell.org/D1123, 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 4 weeks ago by thomie

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

comment:27 Changed 3 weeks 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 repo.msys2.org and GitHub, it might be
more desirable to mirror them on
http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
attempt.

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
`libgcc_s_sjlj-1.dll`.
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
updated.

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: https://phabricator.haskell.org/D1123

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

comment:28 Changed 3 weeks ago by thomie

  • Resolution set to fixed
  • Status changed from patch to closed

Let's close this one as well.

Note: See TracTickets for help on using tickets.