Opened 4 years ago

Closed 2 years ago

#9101 closed feature request (wontfix)

Need option to use system gcc and binutils on Windows/msys2

Reported by: cchantep Owned by: gintas
Priority: normal Milestone:
Component: Build System Version: 7.8.2
Keywords: Cc: gintas
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #9218 Differential Rev(s):
Wiki Page:

Description

Hi,

Trying to build GHC 7.8.2 from sources on Windows 7, from msys2 shell, required binaries such as gcc, ld, ar are forced to those in inplace directories (windows-extra), even system/env provide such tools (e.g. using pacman package manager in msys2): https://ghc.haskell.org/trac/ghc/browser/ghc/configure.ac#L274 .

It leads to issues as tools in inplace are quite old.

Particularly it can be critical about linking: GHC will be working with old ld, but you can have built/linked libraries using the more recent ld. Then, what's built using system tool can't be used throught GHC (ld version conflict).

Change History (4)

comment:1 Changed 3 years ago by gintas

Cc: gintas added

comment:2 Changed 3 years ago by gintas

Owner: set to gintas

I'm looking into this, updating the wikipage as I go.

comment:3 Changed 3 years ago by gintas

Component: CompilerBuild System
Summary: Build 7.8.2 from sources on Windows/msys2Need option to use system gcc and binutils on Windows/msys2
Type: bugfeature request

comment:4 Changed 2 years ago by thomie

Resolution: wontfix
Status: newclosed

Trying to build GHC 7.8.2 from sources on Windows 7, from msys2 shell, required binaries such as gcc, ld, ar are forced to those in inplace directories (windows-extra)

I understand this is by design. Quoting Simon in this email to ghc-devs:

"We physically include very selective chunks of MinGW in a GHC Windows distribution

  • so that users don't need to install MinGW
  • so that GHC doesn't break just because a user has a different version of MinGW than we expected We keep these chunks of MinGW in the GHC repo (in ghc-tarballs) precisely so that we know exactly which bits to ship.

The intention is that the MinGW bits shipped with GHC are essentially invisible to the user. They just see a ghc.exe, which just happens internally to call some Mingw binaries."

But the version of MinGW shipped with GHC at the moment is indeed out of date. Please subscribe to #9218 for updates.

Note: See TracTickets for help on using tickets.