[Backport release-25.05] haskell.compiler.ghc94: don't roundtrip C compilation via assembly#411716
Conversation
github-actions
bot
added
6.topic: haskell
nix-owners
bot
requested review from
maralorn,
sternenseemann and
wolfgangwalther
github-actions
bot
added
10.rebuild-darwin: 1-10
|
The check-cherry-picks job failed, because the commit is in haskell-updates. Should we update the script to also recognize haskell-updates as an allowed branch to pick from? I think that would make sense. |
Did that in #411709. |
wolfgangwalther
force-pushed
the
backport-410085-to-release-25.05
branch
from
e82afa1 to
7ba6092
Compare
|
As discussed in #411397 (comment), added the first 3 commits of #411397. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
I'm not aware of this failure? |
Not sure what you mean. Logs are in the comment above. |
This is more robust when new bindists are added to expressions since no additional conditional needs to be updated. (cherry picked from commit 3c3fef0)
We can/should use 9.0.2 to bootstrap some GHC versions, having the bindist makes things easier in some cases. - To bootstrap GHC 9.4 using 9.2 is not possible and 8.10.7 doesn't always work. Since source built 9.0.2 is broken on darwin at the moment, the bindist helps. Reference #367686, #410085. - To bootstrap GHC 9.2 without GHC 8.10. Reference #346214. (cherry picked from commit 221e06a)
(cherry picked from commit da08e91)
GHC can be used to compile C sources which causes it to drive the configured C compiler. This is particularly relevant during GHC's own compilation, e.g. when building the rts. GHC takes a peculiar approach, always generating intermediate assembly instead of letting the C compiler emit object files directly. This causes an assembler check in clang >= 18 to fail on rts/StgCRun.c, failing the GHC build on darwin completely. Later GHC versions don't exhibit this issue since object code is emitted directly since 9.6. The easiest way to resolve the compilation failure seems to backport this change. However, the patch only applies on GHC 9.4 which is done here. The patch may be difficult to backport further, as the changed code was extensively refactored in GHC 9.4. Reference #367686. (cherry picked from commit 16dca70)
wolfgangwalther
force-pushed
the
backport-410085-to-release-25.05
branch
from
7ba6092 to
5ebbed3
Compare
github-actions
bot
dismissed
their stale review
All cherry-picks are good now, thank you!
sternenseemann
left a comment
sternenseemann
left a comment
There was a problem hiding this comment.
@wolfgangwalther can we trust the rebuild count for aarch64 now as well? If so, feel free to merge.
|
Yeah, the eval + rebuild counts should be fully platform-specific for a while now. GHC 9.4 on darwin is still broken, but it was before this PR as well. Hopefully we can still fix this, this currently prevents me from updating nixpkgs in PostgREST (where we are still stuck on GHC 9.4, because of the pkgsStatic stuff). |
nixpkgs-ci
bot
added
the
12.approvals: 1
nixpkgs-ci
bot
added
the
12.approved-by: package-maintainer
|
I'm optimistic a backport of #421477 will fix the 9.4 issue. |
2 participants
Bot-based backport to
release-25.05, triggered by a label in #410085.