LLVM errors when building on `macOS-latest` with `ghc-{8.10,9.0}`.

[jonathanknowles]

Hi there!

I'm not sure whether this is an issue with haskell-actions per se, but I thought it worth recording in case others are also running into the same issue.

Affected OS, GHC, and cabal version combinations

	macOS-latest	windows-latest	ubuntu-latest
ghc-8.10	🔴 affected	🟢 unaffected	🟢 unaffected
ghc-9.0	🔴 affected	🟢 unaffected	🟢 unaffected
ghc-9.2	🟢 unaffected	🟢 unaffected	🟢 unaffected
ghc-9.4	🟢 unaffected	🟢 unaffected	🟢 unaffected
ghc-9.6	🟢 unaffected	🟢 unaffected	🟢 unaffected
ghc-9.8	🟢 unaffected	🟢 unaffected	🟢 unaffected

Building with cabal-3.10.3.0.

Known workarounds

• Use macOS-13 instead of macOS-latest.

Issue

On affected OS platform and GHC versions, there are LLVM-related build failures similar to the following:

> cabal build all --builddir=b --only-dependencies
Building     StateVar-1.2.2 (lib)
Configuring library for StateVar-1.2.2..
Preprocessing library for StateVar-1.2.2..
Building library for StateVar-1.2.2..

<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM between [9 and 13)
[1 of 1] Compiling Data.StateVar    ( src/Data/StateVar.hs, dist/build/Data/StateVar.o, dist/build/Data/StateVar.dyn_o )

<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM between [9 and 13)
ghc: could not execute: opt 

Note that the LLVM error appears for whatever dependency cabal is attempting to build first. (It's not specific to StateVar.)

Example action failures

• https://github.com/IntersectMBO/bech32/actions/runs/8861664911/job/24411967208#step:7:121
• https://github.com/jonathanknowles/haskell-example/actions/runs/8861645867/job/24408711792#step:7:78
• https://github.com/jonathanknowles/monoidmap/actions/runs/8861721580/job/24341958036#step:7:277

[andreasabel]

E.g. I looked at monoidmap but could not see anything LLVM specific. Are you using the LLVM backend (actively) or are these just vanilla builds failing?

Last successful run: macos-12 20240418.1 https://github.com/jonathanknowles/monoidmap/actions/runs/8837441351/job/24266315402#step:1:9
First failing run: macos-14-arm64 20240422.3 https://github.com/jonathanknowles/monoidmap/actions/runs/8852545287/job/24311465110#step:1:9

Maybe it is the switch from amd64 to arm64 that breaks things. You could fix the runner to macos-12 to circumvent this problem. But yes, many others will get the problem as well...

@jonathanknowles Have you tried patching your workflows with an explicit LLVM installation step? I would be curious if that fixed the problem.

[ulysses4ever]

In the case of Cabal, we did see some failures due to missing LLVM on the new MacOS runners and that was one of several reasons we rolled back to macos-13. Here's an example run if that's of any help: https://github.com/haskell/cabal/actions/runs/8864213938/job/24339171647

[jonathanknowles]

Many thanks for commenting so quickly @andreasabel!

E.g. I looked at monoidmap but could not see anything LLVM specific. Are you using the LLVM backend (actively) or are these just vanilla builds failing?

My apologies -- here's a more direct link to the actual failure: https://github.com/jonathanknowles/monoidmap/actions/runs/8861721580/job/24341958036#step:7:277

(I've also updated all the links in the "example action failures" section to link to the precise parts that failed.)

[jonathanknowles]

@andreasabel wrote:

Maybe it is the switch from amd64 to arm64 that breaks things. You could fix the runner to macos-12 to circumvent this problem. But yes, many others will get the problem as well...

@ulysses4ever wrote:

In the case of Cabal, we did see some failures due to missing LLVM on the new MacOS runners and that was one of several reasons we rolled back to macos-13.

Thanks!

I can confirm that rolling back to macOS-13 also solves the problem for me:

• https://github.com/jonathanknowles/haskell-example/actions/runs/8905104439?pr=39
  ✅ builds for all major GHC versions from 8.10 to 9.8 🎉

---

According to the table below (source) macOS-13 seems to be the most-recent "non-large" Intel macOS image:

Image	YAML Label	Included Software	Rollout Status of Latest Image Release
macOS 14	macos-latest-large or macos-14-large	macOS-14
macOS 14 Arm64	macos-latest, macos-14, macos-latest-xlarge or macos-14-xlarge	macOS-14-arm64
macOS 13	macos-13 or macos-13-large	macOS-13
macOS 13 Arm64	macos-13-xlarge	macOS-13-arm64
macOS 12	macos-12 or macos-12-large	macOS-12

(I did try to build with macOS-latest-large but that apparently requires a paid plan, which I don't have.)

[jonathanknowles]

@andreasabel wrote:

Have you tried patching your workflows with an explicit LLVM installation step? I would be curious if that fixed the problem.

I did very briefly experiment with this, but didn't succeed yet. (https://github.com/jonathanknowles/haskell-example/actions/runs/8905557298/job/24456432075?pr=40)

[andreasabel]

@jonathanknowles : I noticed in your experiment some non-idiomatic ways to handle the environment, see my comments at jonathanknowles/haskell-example@ce66f88.
(Maybe this is why it did not succeed?)

[andreasabel]

I am reproducing the failure now on the local CI here: https://github.com/haskell-actions/setup/actions/runs/8941784591/job/24562918002

[andreasabel]

Installing LLVM 12 on macos-14 did not help, or I did not do it correctly: https://github.com/andreasabel/gha-test/actions/runs/8942210516/job/24564290977