Improve support for aarch64

[avdv]

Fixes #1823
Fixes #1809
Fixes #1821

Depends on #1808

[dpulls]

🎉 All dependencies have been resolved !

[phb]

We've tested this and it works fine, I've gotten to the point where I can see haskell packages being compiled using ghc 9.2.

There are a few other issues though

1. It seems all ghc versions <9.2 (?) uses LLVM to compile. Bazel rules clears PATH and as such it won't find opt (from llvm) on M1 macbooks as they don't allow installing things in the system bin folders.
   I can't think of any good solutions here -- it doesn't seem right to have rules_haskell setup the path to a local installation of llvm as that kind of defeats the purpose of hermetic builds, that said, I don't want rules_haskell to download and build llvm either!
2. haskell 9.2 doesn't really seem ready for prime-time (no lts stackage snapshot and trying one of the nightlies I'm observing build failures) (I'm not a haskell person, so sorry if my vocabulary here is totally incorrect -- just trying to fix the build of an existing project after getting M1 laptops)

(update): So it seems the errors I'm seeing when using the nightly snapshot is actually the same error previously reported as fixed here:
20085b2 but I believe later reverted here: ed9ca34

Error being this:

../../../bazel-out/darwin_arm64-fastbuild/bin/external/stackage/transformers-compat-0.7.2/transformers-compat-0.7.2/build/autogen/Paths_transformers_compat.hs:48:17: error:
    Variable not in scope: splitFileName :: FilePath -> (a, b0)
   |
48 |   let (dir,_) = splitFileName exePath
   |                 ^^^^^^^^^^^^^

../../../bazel-out/darwin_arm64-fastbuild/bin/external/stackage/transformers-compat-0.7.2/transformers-compat-0.7.2/build/autogen/Paths_transformers_compat.hs:49:16: error:
    Variable not in scope: minusFileName :: t0 -> String -> String
   |
49 |   return ((dir `minusFileName` "bin") `joinFileName` dirRel)

[avdv]

• It seems all ghc versions <9.2 (?) uses LLVM to compile. Bazel rules clears PATH and as such it won't find opt (from llvm) on M1 macbooks as they don't allow installing things in the system bin folders.

The compiler backend is configurable. See https://downloads.haskell.org/ghc/latest/docs/users_guide/codegens.html#llvm-code-gen

So you could pass -fasm to ghc to use the native backend.

I can't think of any good solutions here -- it doesn't seem right to have rules_haskell setup the path to a local installation of llvm as that kind of defeats the purpose of hermetic builds, that said, I don't want rules_haskell to download and build llvm either!

• haskell 9.2 doesn't really seem ready for prime-time (no lts stackage snapshot and trying one of the nightlies I'm observing build failures) (I'm not a haskell person, so sorry if my vocabulary here is totally incorrect -- just trying to fix the build of an existing project after getting M1 laptops)
  (update): So it seems the errors I'm seeing when using the nightly snapshot is actually the same error previously reported as fixed here:
  20085b2 but I believe later reverted here: ed9ca34

Yes, we need the modules to be relocatable. Unfortunately, this has been broken in Cabal since version 3.6.0 and was only recently fixed by haskell/cabal#8220.

[phb]

• It seems all ghc versions <9.2 (?) uses LLVM to compile. Bazel rules clears PATH and as such it won't find opt (from llvm) on M1 macbooks as they don't allow installing things in the system bin folders.

The compiler backend is configurable. See https://downloads.haskell.org/ghc/latest/docs/users_guide/codegens.html#llvm-code-gen

So you could pass -fasm to ghc to use the native backend.

I don't believe this will work on versions prior to 9.2 as it didn't have a native backend for arm64 until then (assuming I read the release notes correctly: https://discourse.haskell.org/t/ghc-9-2-1-released/3527)

I can't think of any good solutions here -- it doesn't seem right to have rules_haskell setup the path to a local installation of llvm as that kind of defeats the purpose of hermetic builds, that said, I don't want rules_haskell to download and build llvm either!

• haskell 9.2 doesn't really seem ready for prime-time (no lts stackage snapshot and trying one of the nightlies I'm observing build failures) (I'm not a haskell person, so sorry if my vocabulary here is totally incorrect -- just trying to fix the build of an existing project after getting M1 laptops)
  (update): So it seems the errors I'm seeing when using the nightly snapshot is actually the same error previously reported as fixed here:
  20085b2 but I believe later reverted here: ed9ca34

Yes, we need the modules to be relocatable. Unfortunately, this has been broken in Cabal since version 3.6.0 and was only recently fixed by haskell/cabal#8220.

ah, that's great news -- don't think there is much to do except to wait for that commit to end up in a cabal release then. Let me know if you have any other ideas how to work around this.

I think ghc really should have a way for the user to provide a path to the llvm installation at runtime instead of relying on PATH. That said, considering that's not available now, perhaps we could add an option to rules_haskell to extend PATH in the ghc rule for finding required tools (based on the backend selected)?

[avdv]

I think ghc really should have a way for the user to provide a path to the llvm installation at runtime instead of relying on PATH.

Well, it does. You can use the various flags to set up a specific command for a tool.

See https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/phases.html?highlight=pgmlo#replacing-the-program-for-one-or-more-phases

[phb]

I think ghc really should have a way for the user to provide a path to the llvm installation at runtime instead of relying on PATH.

Well, it does. You can use the various flags to set up a specific command for a tool.

See https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/phases.html?highlight=pgmlo#replacing-the-program-for-one-or-more-phases

ah, that should unblock us. Thanks for that pointer -- I think we're good!

[GuillaumeGen]

Sorry, I merged the support for GHC 9.2.5 just before reviewing this, creating conflicts. They seemed simple to solve, but you may check that I did not miss anything.
Otherwise, looks great!

[avdv]

Thank you, @GuillaumeGen ! I manually rebased against the default branch and removed the GHC prefixes, lib and so on for GHC 9.2.5 so it is also handled generically.