feat(ghc): add GHC 9.10.3 support for ARM64 macOS

[lexfrei]

Summary

Add support for GHC 9.10.3 across supported platforms (Linux and macOS).

• Add stackage snapshot configuration using LTS 24.19
• Update CI workflow matrix to test GHC 9.10.3
• Exclude Windows and bzlmod builds (consistent with recent GHC versions)

Changes

• Created stackage_snapshot_9.10.3.yaml with LTS 24.19 resolver
• Added GHC 9.10.3 to CI test matrices for nixpkgs and bindist workflows
• Added symlink in rules_haskell_tests/ for test snapshot

Notes

The GHC 9.10.3 binary distributions already exist in ghc_bindist_generated.json for all platforms (darwin_amd64, darwin_arm64, linux_amd64, linux_arm64, windows_amd64).

Windows and bzlmod support excluded following the pattern of GHC 9.6.5 and 9.8.2.

Test Plan

• CI will test GHC 9.10.3 on Ubuntu 24.04 and macOS 14
• Both nixpkgs and bindist toolchains will be tested
• All three workspaces (rules_haskell, rules_haskell_nix, rules_haskell_tests) covered

[avdv]

Thank you, that looks good!

The only real error on CI (apart from the ones due to haskell/hackage-server#1366 and because of #2346) is this:

ERROR: /Users/runner/work/rules_haskell/rules_haskell/rules_haskell_tests/tests/ghcide/BUILD.bazel:5:9: no such package '@ghcide-exe//ghcide': no such package '@ghcide//': Not a regular file: /Users/runner/work/rules_haskell/rules_haskell/rules_haskell_tests/ghcide-snapshot_9.10.3.json and referenced by '//tests/ghcide:ghcide'

You need to run GHC_VERSION=9.10.3 bazel @ghcide-unpinned//:pin and commit the ghcide-snapshot_9.10.3.json file.

[lexfrei]

@avdv Thanks for the review! Fixed and pushed.

The ghcide-snapshot_9.10.3.json generation required two additional fixes in ghcide-stack-snapshot_9.10.3.yaml:

1. Fixed resolver: Changed from nightly-2024-12-10 to nightly-2024-12-11 - the former doesn't exist in Stackage (GHC 9.10 nightly started on Dec 11, 2024)

2. Added missing packages: lsp-2.7.0.0 and lsp-types-2.3.0.0 - these are not included in nightly-2024-12-11 but are required dependencies for ghcide 2.9.0.0

[avdv]

@avdv Thanks for the review! Fixed and pushed.

The ghcide-snapshot_9.10.3.json generation required two additional fixes in ghcide-stack-snapshot_9.10.3.yaml:

1. **Fixed resolver**: Changed from `nightly-2024-12-10` to `nightly-2024-12-11` - the former doesn't exist in Stackage (GHC 9.10 nightly started on Dec 11, 2024)

2. **Added missing packages**: `lsp-2.7.0.0` and `lsp-types-2.3.0.0` - these are not included in `nightly-2024-12-11` but are required dependencies for ghcide 2.9.0.0

Thanks, that makes sense. I just pushed some changes to use an lts revision instead of a nightly and pinned the two other snapshots. Hopefully, these will succeed now. 🤞

\edit: it failed for the test-haddock test which needs to be adapted to new compiler versions. I took the opportunity to replace the test with a unittest that checks against the output files with version suffixes removed.

[avdv]

I fixed a few of the remaining test failures but there are some left. Could you look into them, I probably won't be able to on the next days?!

[avdv]

I had a deeper look as into why the tests fail.

1. //tests/haskell_cabal_datafiles/compare_other_cabal_functions:same_other_functions

this fails on linux and macOS.

The reason is that Cabal 3.12.0 (which comes with ghc 9.10) behaves a bit differently than prior versions. Instead of using libexec/<arch><os>-ghc-<version> for the libexec path, it uses libexec/<arch><os>-ghc-<version>-<id> -- probably appending the "Project Unit Id" from ghc --info.

The test checks whether our generated path information (with generate_paths_module = true) is the same as the path module generated by Cabal.

I am not sure what we should do here, This difference can probably lead to problems later. Maybe we could inspect the version of Cabal in order to decide whether to append a suffix or not.

2. //tests/indirect-link:indirect-link-dynamic

this test only fails on linux (as it is OS specific). It fails to locate in libtests_Sindirect-link_Slibcbits.so library at runtime:

bazel-out/k8-fastbuild/bin/tests/indirect-link/indirect-link-dynamic.runfiles/rules_haskell_tests/tests/indirect-link/indirect-link-dynamic: error while loading shared libraries: 
libtests_Sindirect-link_Slibcbits.so: cannot open shared object file: No such file or directory

This is probably caused by changes in GHC itself, since with previous versions the indirect-link-dynamic binary was depending directly on the cbits lib:

$ lddtree indirect-link/indirect-link-dynamic
indirect-link-dynamic => indirect-link/indirect-link-dynamic (interpreter => /lib64/ld-linux-x86-64.so.2)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
    libHStestsZSindirect-linkZSmypkg-ghc9.8.2.so => indirect-link/../../_solib_k8/libHStestsZSindirect-linkZSmypkg-ghc9.8.2.so
    libHSbase-4.19.1.0-179c-ghc9.8.2.so => not found
    libHSghc-bignum-1.3-b9ac-ghc9.8.2.so => not found
    libHSghc-prim-0.11.0-7523-ghc9.8.2.so => not found
    libHSrts-1.0.2_thr-ghc9.8.2.so => not found
    libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8
    libtests_Sindirect-link_Slibcbits.so => indirect-link/../../_solib_k8/libtests_Sindirect-link_Slibcbits.so
    libtests_Sindirect-link_Slibcbits-indirect.so => indirect-link/../../_solib_k8/libtests_Sindirect-link_Slibcbits-indirect.so
    libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1

but now, with GHC 9.10.3, the cbits library is just a transitive runtime dependency of libHStestsZSindirect-linkZSmypkg-ghc9.10.3.so:

$ lddtree indirect-link/indirect-link-dynamic
indirect-link-dynamic => indirect-link/indirect-link-dynamic (interpreter => /lib64/ld-linux-x86-64.so.2)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
    libHStestsZSindirect-linkZSmypkg-ghc9.10.3.so => indirect-link/../../_solib_k8/libHStestsZSindirect-linkZSmypkg-ghc9.10.3.so
        libtests_Sindirect-link_Slibcbits.so => not found
    libHSghc-internal-9.1003.0-a081-ghc9.10.3.so => not found
    libHSghc-prim-0.12.0-957b-ghc9.10.3.so => not found
    libHSrts-1.0.2_thr-ghc9.10.3.so => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1

We are setting RUNPATH in ELF files when linking, using $ORIGIN to ensure libraries are found at runtime. But $ORIGIN is relative to the binary or shared library it is used in. Since the cbits lib is no longer needed by the binary itself it only gets resolved as a dependency for the mypkg shared object:

$ readelf -d indirect-link-dynamic | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libHStestsZSindirect-linkZSmypkg-ghc9.8.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libHSbase-4.19.1.0-179c-ghc9.8.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libHSghc-bignum-1.3-b9ac-ghc9.8.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libHSghc-prim-0.11.0-7523-ghc9.8.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libHSrts-1.0.2_thr-ghc9.8.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libffi.so.8]
 0x0000000000000001 (NEEDED)             Shared library: [libtests_Sindirect-link_Slibcbits.so]
 0x0000000000000001 (NEEDED)             Shared library: [libtests_Sindirect-link_Slibcbits-indirect.so]
 0x0000000000000001 (NEEDED)             Shared library: [libgmp.so.10]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]

$ readelf -d indirect-link-dynamic | grep RUNP
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../../_solib_k8:$ORIGIN/../../_solib_k8/external_Srules_Uhaskell_Ughc_Ulinux_Uamd64]

$ cd ../../_solib_k8 # follow the first RUNPATH entry

$ readelf -d libHStestsZSindirect-linkZSmypkg-ghc9.8.2.so | grep RUNPATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../../_solib_k8:$ORIGIN/../../_solib_k8/external_Srules_Uhaskell_Ughc_Ulinux_Uamd64]

$ ls ../../_solib_k8
ls: cannot access '../../_solib_k8': No such file or directory

$ ls ../../_solib_k8/external_Srules_Uhaskell_Ughc_Ulinux_Uamd64
ls: cannot access '../../_solib_k8/external_Srules_Uhaskell_Ughc_Ulinux_Uamd64': No such file or directory

To fix this, we probably need to add the current directory (i.e. $ORIGIN itself) to the RUNPATH.