haskell.compiler.ghc9{6,8}: work around output cycles on aarch64-darwin#258280
haskell.compiler.ghc9{6,8}: work around output cycles on aarch64-darwin#258280sternenseemann merged 1 commit intoNixOS:haskell-updatesfrom
Conversation
|
Let's see if ofborg is able to build this for us to test: @ofborg build haskell.packages.ghc963.ormolu (edit: this appears to fail on aarch64-darwin, but it looks just like an expected timeout? Likely not related to the patch added in this PR.) |
|
@cdepillabout looks like it failed because |
|
@mpscholten It appears that It appears to be timing out for aarch64 (which is likely expected, given that ofborg will timeout with long builds, and ghc is a long build). Also, in the future, I think you should be able to run ofborg yourself, just by giving a similar (edit: Oh, I just took a better look at the error message, and it appears you're right! Only on aarch64-darwin, it is giving an error message that ghc-9.6.3 doesn't exist. I have no idea why that would be happening. Possibly ofborg is just completely busted on aarch64-darwin.) |
|
Thanks, didn't know I can also trigger ofborg. This is good to know 👍 Let's see if a rebuild on ghc962 helps here @ofborg build haskell.packages.ghc962.ormolu I also started a build of this branch on the IHP M1 build server at https://github.com/digitallyinduced/ihp/actions/runs/6370225675/job/17291191691 |
|
It seems like |
Hey, sorry I hadn't gotten back to you. Is this PR still stuck on waiting for https://gitlab.haskell.org/ghc/ghc/-/issues/24041 to be fixed? |
|
Yes, looks like a fix was merged for GHC 9.8.x but no backport for 9.6.x yet |
|
@mpscholten Do you mind if I convert this to a draft since we are still waiting on upstream for a fix for 9.6? (If I've misunderstood, and this shouldn't be put into a draft, feel free to switch it back to non-draft.) |
|
As far as I understand the fix here is actually independent of that GHC issue. So even when GHC has merged that fix, I think this issue here will still happen unless the PR is merged |
Ah, so just so I understand, in order to fix the issue you're running into, both of the following things need to happen:
That is to say, if either GHC is patched without merging this PR, or this PR is merged without GHC being patched, it won't fix the issue, correct? |
2c4decc to
92835bb
Compare
This ports our infamous patch for `Cabal` which cheesily prevents an output cycle for derivations that use separate bin outputs where references caused by the `Paths_*` module can't be eliminated by the GHC aarch64-darwin codegen backend. See also - the original issue NixOS#140774, - the original patch for GHC 9.2 NixOS#216857 - the ported patch for GHC 9.4 NixOS@f6f780f Co-authored-by: sternenseemann <sternenseemann@systemli.org>
92835bb to
ad424bf
Compare
|
Nice! |
Description of changes
Fix for #255037 (comment)
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)