Skip to content

haskell.compiler.ghc91{0,2}: provide LLVM compatible assembler#440761

Merged
sternenseemann merged 3 commits intoNixOS:masterfrom
sternenseemann:ghc-get-tool-exe
Sep 12, 2025
Merged

haskell.compiler.ghc91{0,2}: provide LLVM compatible assembler#440761
sternenseemann merged 3 commits intoNixOS:masterfrom
sternenseemann:ghc-get-tool-exe

Conversation

@sternenseemann
Copy link
Member

@sternenseemann sternenseemann commented Sep 6, 2025 •
edited
Loading

Verified that there are no hash changes (eval platform x86_64-linux) due to getToolExe in:

  • haskell.compiler
  • pkgsCross.armv7l-hf-multiplatform.haskell.compiler
  • pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler

Tested pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc9102 with LLVMAS.

Things done

  • Built on platform:
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • Tested, as applicable:
  • Ran nixpkgs-review on this PR. See nixpkgs-review usage.
  • Tested basic functionality of all binary files, usually in ./result/bin/.
  • Nixpkgs Release Notes
    • Package update: when the change is major or breaking.
  • NixOS Release Notes
    • Module addition: when adding a new NixOS module.
    • Module update: when the change is significant.
  • Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

Add a 👍 reaction to pull requests you find important.

@nixpkgs-ci nixpkgs-ci bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. 6.topic: haskell General-purpose, statically typed, purely functional programming language labels Sep 6, 2025
@nixpkgs-ci nixpkgs-ci bot added 9.needs: reviewer This PR currently has no reviewers requested and needs attention. and removed 9.needs: reviewer This PR currently has no reviewers requested and needs attention. labels Sep 6, 2025
@sternenseemann sternenseemann changed the title haskell.compiler.*: add helper for calculating LLVM tools' paths haskell.compiler.ghc91{0,2}: provide LLVM compatible assembler Sep 6, 2025
@sternenseemann sternenseemann mentioned this pull request Sep 6, 2025
Merged
13 tasks
emilazy
emilazy approved these changes Sep 6, 2025
View reviewed changes
Copy link
Member

@emilazy emilazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks correct to me. Haven’t tested, but it can’t make anything worse for Hydra‐supported platforms and is already broken for LLVM‐using ones, so it seems harmless to land preemptively.

It‘d be nice to land this on master, as it will make it easier to test #440774 with these versions. (Unless we’re sending that one to haskell-updates too.)

@sternenseemann
Copy link
Member Author

sternenseemann commented Sep 7, 2025

Yeah, I'll rebase it tomorrow.

@nixpkgs-ci nixpkgs-ci bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Sep 7, 2025
@sternenseemann sternenseemann changed the base branch from haskell-updates to master September 7, 2025 10:13
@nixpkgs-ci nixpkgs-ci bot closed this Sep 7, 2025
@nixpkgs-ci nixpkgs-ci bot reopened this Sep 7, 2025
@sternenseemann
Copy link
Member Author

sternenseemann commented Sep 7, 2025 •
edited
Loading

Rebased on master though merge-base with haskell-updates which doesn't seem to matter at the moment.

@wolfgangwalther
Copy link
Contributor

wolfgangwalther commented Sep 7, 2025

Now conflicted with 8.10.7.nix.

@nixpkgs-ci nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Sep 7, 2025
@sternenseemann
Copy link
Member Author

sternenseemann commented Sep 7, 2025

Now conflicted with 8.10.7.nix.

😢

Rebased.

@nixpkgs-ci nixpkgs-ci bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Sep 7, 2025
@emilazy
Copy link
Member

emilazy commented Sep 8, 2025

I guess forceLlvmCodegenBackend may need updating? Or just dropping – it looks like it is only used for 9.6.3, which seems like it won’t be long for this world anyway.

@emilazy emilazy mentioned this pull request Sep 8, 2025
Merged
13 tasks
@sternenseemann
Copy link
Member Author

sternenseemann commented Sep 8, 2025

@emilazy Done, incorporated some of your changes from #441101.

emilazy
emilazy approved these changes Sep 9, 2025
View reviewed changes
Copy link
Member

@emilazy emilazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still haven’t tested, but looks sensible.

@emilazy
Copy link
Member

emilazy commented Sep 9, 2025

Hmm, actually, with-packages-wrapper.nix should probably not be doing inherit (haskellPackages) llvmPackages and I’m wondering how that didn’t break on my PR.

@emilazy emilazy mentioned this pull request Sep 9, 2025
Merged
1 task
@sternenseemann
Copy link
Member Author

sternenseemann commented Sep 9, 2025

Hmm, actually, with-packages-wrapper.nix should probably not be doing inherit (haskellPackages) llvmPackages and I’m wondering how that didn’t break on my PR.

This feature is mostly for convenience downstream and appears not to be used in Nixpkgs at all. In light of this, I've added a test in #441471.

@sternenseemann
haskell.compiler.*: add helper for calculating LLVM tools' paths
cdb8e81 
Verified that there are no hash changes (eval platform x86_64-linux) in:

- haskell.compiler
- pkgsCross.armv7l-hf-multiplatform.haskell.compiler
- pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler
@sternenseemann
haskell.compiler.ghc91{0,2}: provide LLVM compatible assembler
a9e965e 
If we don't explicitly pass something as LLVMAS, GHC >= 9.10 will try to
invoke "clang" at runtime which fails.

Upstream change: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12005

I've tested pkgsCross.armv7l-hf-multiplatform.buildPackages.haskell.compiler.ghc9102
which was reported to be failing here:
NixOS#440271 (comment)
@sternenseemann
{forceLlvmCodegenBackend,ghcWithPackages}: update clang -fllvm logic
a2b6624 
- The LLVM backend always needs an LLVM specific assembler, i.e. clang
  that ideally matches the version of LLVM actually used for codegen.

- The LLVM backend on Darwin requires some version of clang to be
  available. In light of LLVMAS, using a matching version seems to be
  best though this does risk messing with clang used for compiling C
  in the derivation.

  This mess can be avoided by compiling GHC with useLLVM = true which
  sets absolute paths in GHC's settings file. Due to closure size
  constraints, we can't really do that if NCG is available.
@sternenseemann
Copy link
Member Author

sternenseemann commented Sep 11, 2025 •
edited
Loading

Rebased and tested

  • tests.haskell.ghcWithPackages
  • haskell.packages.ghc963.tls (aarch64-linux)
  • haskell.packages.ghc963.tls (aarch64-darwin)

Does anyone want to take another look?

@sternenseemann sternenseemann added this pull request to the merge queue Sep 12, 2025
Merged via the queue into NixOS:master with commit e288ae7 Sep 12, 2025
30 of 32 checks passed
@sternenseemann sternenseemann deleted the ghc-get-tool-exe branch September 12, 2025 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@emilazy emilazy emilazy approved these changes

@wolfgangwalther wolfgangwalther Awaiting requested review from wolfgangwalther

@maralorn maralorn Awaiting requested review from maralorn

Assignees

No one assigned

Labels

6.topic: haskell General-purpose, statically typed, purely functional programming language 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux. 12.approvals: 1 This PR was reviewed and approved by one person.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@sternenseemann @wolfgangwalther @emilazy