Opened 4 years ago
Closed 3 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 4 years ago by
| Cc: | gintas added |
|---|
comment:2 Changed 4 years ago by
| Owner: | set to gintas |
|---|
comment:3 Changed 3 years ago by
| Component: | Compiler → Build System |
|---|---|
| Related Tickets: | → #9218 |
| Summary: | Build 7.8.2 from sources on Windows/msys2 → Need option to use system gcc and binutils on Windows/msys2 |
| Type: | bug → feature request |
comment:4 Changed 3 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
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.
I'm looking into this, updating the wikipage as I go.