haskell.compiler.ghc*: use matching CLANG & CC on Darwin with LLVM#338782
Merged
sternenseemann merged 1 commit intoNixOS:haskell-updatesfrom Sep 14, 2024
Merged
Conversation
Member
Author
|
The current issue can be observed best when building with import ./. { localSystem = "aarch64-darwin"; }; haskell.lib.compose.overrideCabal { configureFlags = [ "--ghc-option=-v3" ]; } haskell.packages.ghc8107.crypton |
Member
Author
|
Verified compilation of crypton with GHC 9.0.2 and 8.10.7. Note that the tests with 9.0.2 still fail due to kazu-yamamoto/crypton#35. |
13 tasks
sternenseemann
added a commit
to sternenseemann/nixpkgs
that referenced
this pull request
Sep 8, 2024
Note that the clang command should be adapted in the future as done for CLANG in NixOS#338782.
sternenseemann
added a commit
that referenced
this pull request
Sep 8, 2024
Note that the clang command should be adapted in the future as done for CLANG in #338782.
The Darwin LLVM backend of GHC (which is mostly interesting for GHC < 9.2) uses clang as configured via the CLANG environment variable as an assembler. Since it processes outputs of clang as configured via the CC variable, we need to make sure these versions match or risk CLANG clang not understanding the output of CC clang. In the past this wasn't really a problem as due to the fairly old default clang version in the stdenv, clang 11 would be used for CC. CLANG would always be a newer version and deal with the output without any problems. Ever since the upgrade of the default clang version for darwin (bcbdb80), CC would often be a newer version of clang than CLANG, causing build problems in some packages like crypton (for GHC 8.10.7 and 9.0.2 on aarch64-darwin where the darwin LLVM backend was actually used).
04b3de4 to
19c88fb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Darwin LLVM backend of GHC (which is mostly interesting for GHC < 9.2) uses clang as configured via the CLANG environment variable as an assembler. Since it processes outputs of clang as configured via the CC variable, we need to make sure these versions match or risk CLANG clang not understanding the output of CC clang.
In the past this wasn't really a problem as due to the fairly old default clang version in the stdenv, clang 11 would be used for CC. CLANG would always be a newer version and deal with the output without any problems.
Ever since the upgrade of the default clang version for darwin (bcbdb80), CC would often be a newer version of clang than CLANG, causing build problems in some packages like crypton (for GHC 8.10.7 and 9.0.2 on aarch64-darwin where the darwin LLVM backend was actually used).
Description of changes
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.