search

haskell-actions / setup

Setting up GHC, cabal, stack on for Haskell-related CIs
MIT License
41 stars 12 forks source link

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

Open jonathanknowles opened 3 months ago

jonathanknowles commented 3 months ago

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

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

andreasabel commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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:

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 Endpoint Badge
macOS 14 Arm64 macos-latest, macos-14, macos-latest-xlarge or macos-14-xlarge macOS-14-arm64 Endpoint Badge
macOS 13 macos-13 or macos-13-large macOS-13 Endpoint Badge
macOS 13 Arm64 macos-13-xlarge macOS-13-arm64 Endpoint Badge
macOS 12 macos-12 or macos-12-large macOS-12 Endpoint Badge

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

jonathanknowles commented 3 months ago

@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 commented 3 months ago

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

andreasabel commented 3 months ago

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

andreasabel commented 3 months ago

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

jorisdral commented 3 months ago

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

For what it's worth, I've tried similar approaches and it didn't work either

BebeSparkelSparkel commented 1 month ago

I have gotten this to work on the mono-traversable repo https://github.com/snoyberg/mono-traversable/pull/226