GHC 7.10.3 (and later) don't compile on NixOS #10752
Comments
|
Have you reported this issue to the |
|
I haven't yet, since I don't know whether this is a GHC bug. It would be useful to a bisect to a specific commit. What's the best way to do that ( |
|
If you have a local checkout of the repository, then you can enter a build environment ( From the looks of it, it appears to me that GHC tries to link |
|
I get Do I need to write a special |
|
Ah! I think I got it... |
|
So the issue I have is that |
|
Seems to me like this is the offending GHC commit: ghc/ghc@296bc70 I'll investigate a bit more and try to file a GHC ticket. |
|
I created a GHC ticket: https://ghc.haskell.org/trac/ghc/ticket/11147 |
|
ghc 7.10.3 has the same issue: http://hydra.cryp.to/build/1411032/log/raw |
peti
added
0.kind: bug
and removed
9.needs: reporter feedback
old-label: update-package
labels
On Windows, we're constrained to 32k bytes total for command line arguments. When building large projects, this limit can be exceeded. This patch changes GHC to always use response files for linker arguments, a feature first used by Microsoft compilers and added to GCC (over a decade ago). Alternatives here include: * Only use this method on Windows systems * Check the length of the command line arguments and use that to decide whether to use this method I did not pursue either of these, as I believe it would make the patch more likely to break in less tested situations. Test Plan: Confirm that linking still works in general. Ideally: compile a very large project on Windows with this patch. (I am attempting to do that myself now, but having trouble getting the Windows build tool chain up and running.) Reviewers: goldfire, hvr, rwbarton, austin, thomie, bgamari, Phyx Reviewed By: thomie, bgamari, Phyx Subscribers: erikd, awson, #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D1158 GHC Trac Issues: #8596, #10777
The new GHC version contains a patch [1] that passes linker and compiler flags to GCC via response files rather than directly on the command-line. This is supposed to be beneficial on Windows and other platforms that have trouble dealing with long argument lists. On NixOS, however, this feature breaks the flag handling provided by gcc-wrapper [2] and therefore causes the entire GHC build to fail. This issue has been reported upstream at [3]. It's not clear yet how to remedy this problem, but until we've figured that out we just don't pass compiler flags in response files on NixOS to fix #10752. [1] ghc/ghc@296bc70 [2] #11762 [3] https://ghc.haskell.org/trac/ghc/ticket/11147 (cherry picked from commit a421e7b)
ghost
mentioned this issue
haskell.compiler.ghcHEAD: fix patchPhase #10752
The new GHC version contains a patch [1] that passes linker and compiler flags to GCC via response files rather than directly on the command-line. This is supposed to be beneficial on Windows and other platforms that have trouble dealing with long argument lists. On NixOS, however, this feature breaks the flag handling provided by gcc-wrapper [2] and therefore causes the entire GHC build to fail. This issue has been reported upstream at [3]. It's not clear yet how to remedy this problem, but until we've figured that out we just don't pass compiler flags in response files on NixOS to fix NixOS#10752. [1] ghc/ghc@296bc70 [2] NixOS#11762 [3] https://ghc.haskell.org/trac/ghc/ticket/11147 (cherry picked from commit a421e7b)
…aster Closes NixOS#10752. (cherry picked from commit 1f10849)
The
ghcHEADpackage is currently pinned at a commit from 2015-08-28. I attempted to update it to a commit dated 2015-10-30 using the below patch to nixpkgs commit7eea66cabeaaefa0961cf38630a17aee0e2dd536:But with this and other more recent versions of GHC HEAD, I'm getting:
This happens when using the command
Versions:
The text was updated successfully, but these errors were encountered: