Support GHC-9.6 wrt #979

[hasufell]

• Fishy upper bounds: https://github.com/ekmett/semigroupoids/issues/138
• FreeBSD failure: https://gitlab.haskell.org/ghc/ghc/-/issues/24672

---

Mac failure: https://github.com/haskell/ghcup-hs/actions/runs/8686247192/job/23819882230#step:3:12356

ld: multiple errors: archive member 'C_utimensat.o' not a mach-o file in '/Users/github/actions-runner/_work/ghcup-hs/ghcup-hs/cabal/store/ghc-9.6.4/drctry-1.3.8.4-5d2ff4b3/lib/libHSdrctry-1.3.8.4-5d2ff4b3.a'; archive member 'Resource.o' not a mach-o file in '/Users/github/actions-runner/_work/ghcup-hs/ghcup-hs/cabal/store/ghc-9.6.4/nx-2.8.5.1-eabe308a/lib/libHSnx-2.8.5.1-eabe308a.a'

---

Alpine Linux musl failure: https://github.com/haskell/ghcup-hs/actions/runs/8686247192/job/23819882474#step:6:12219

    Error relocating /github/workspace/cabal/store/ghc-9.6.4/streamly-0.8.3-051ad9e56c8a3123bf67ad24d5632d562a809c17782a521307732e0f5462f097/lib/libHSstreamly-0.8.3-051ad9e56c8a3123bf67ad24d5632d562a809c17782a521307732e0f5462f097-ghc9.6.4.so: u_iswspace: symbol not found

[mpickering]

It seems the mac failure is something related to homebrew and coreutils.

See here: https://forums.developer.apple.com/forums/thread/741149 which links to here: https://github.com/pyenv/pyenv/issues/2862 which then suggests that coreutils on PATH may be the issue: https://github.com/pyenv/pyenv/wiki/Common-build-problems#keg-only-homebrew-packages-are-forcibly-linked--added-to-path

It's recommended to use the system toolchain if possible on darwin, especially for CC, LD etc.

[mpickering]

The alpine failure is because you are using a version of streamly which doesn't support ghc-9.6. It seems that more recent versions remove the usage of this symbol (which was provided by base but is no longer), can you upgrade to the most recent version of streamly?

[hasufell]

@mpickering thanks for the help

It's recommended to use the system toolchain if possible on darwin, especially for CC, LD etc.

Aren't you using LLVM from nixpkgs in GHC CI too?

https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/darwin/toolchain.nix?ref_type=heads#L99

I'm a bit confused. Why did brew work with a previous GHC? Maybe I try to update LLVM.

can you upgrade to the most recent version of streamly?

Not easily.

[mpickering]

@mpickering thanks for the help

It's recommended to use the system toolchain if possible on darwin, especially for CC, LD etc.

Aren't you using LLVM from nixpkgs in GHC CI too?

https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/darwin/toolchain.nix?ref_type=heads#L99

I'm a bit confused. Why did brew work with a previous GHC? Maybe I try to update LLVM.

In the script you link to you can see we set LLC and OPT to binaries from the nixpkgs provided LLVM but not CC. These binaries are only used when -fllvm option is used.

In the links I posted it seems something changed in Xcode 15 which might have broken the scripts you had. In any case it doesn't normally work to mix a clang and gcc based toolchain, so can you try removing coreutils as the links suggested this could cause the problems.

[hasufell]

Streamly is broken for us:

• https://github.com/composewell/streamly/issues/2738
• https://github.com/composewell/streamly/issues/2739

[hasufell]

9.6.5 seems to be broken on FreeBSD. I'm not sure if that's a packaging issue or something else:

/usr/local/bin/ld: /root/.cache/act/055d04064c7ee56d/hostexecutor/.ghcup/ghc/9.6.5/lib/ghc-9.6.5/lib/../lib/x86_64-freebsd-ghc-9.6.5/ghc-9.6.5/libHSghc-9.6.5.a: error adding symbols: malformed archive

https://github.com/stable-haskell/haskell-language-server/actions/runs/8802881591/job/24159686770#step:5:8184

[hasufell]

@mpickering I don't see where the build on macOS aarch64 is using gcc.

This is the export now:

          export PATH="$HOME/.brew/bin:$HOME/.brew/sbin:$HOME/.brew/opt/llvm@${{ env.LLVM_VER }}/bin:$PATH"
          export CC="$HOME/.brew/opt/llvm@${{ env.LLVM_VER }}/bin/clang"
          export CXX="$HOME/.brew/opt/llvm@${{ env.LLVM_VER }}/bin/clang++"
          export LD="$HOME/.brew/opt/llvm@${{ env.LLVM_VER }}/bin/lld"
          export AR="$HOME/.brew/opt/llvm@${{ env.LLVM_VER }}/bin/llvm-ar"
          export RANLIB="$HOME/.brew/opt/llvm@${{ env.LLVM_VER }}/bin/llvm-ranlib"

Everything is set to clang/llvm.

https://github.com/haskell/ghcup-hs/actions/runs/8896256670/job/24428487013#step:3:12841

[mpickering]

I looked into this further, the issue turns out to be quite confusing and could be either a cabal issue or ghc issue depending on how you view things.

In ghc-9.6, object merging was changed to use ar -L rather than ld -r when ar supports -L. (!8887)

This breaks cabal because cabal assumes you will use the system linker and the logic there doesn't check if you are using a linker with -L support. This results in nested static archives which results in these missing symbol errors. Ideally this would be fixed in cabal, by removing the assumptions about ar logic, but of course, the further fall out of making these changes is hard to anticipate. See https://gitlab.haskell.org/ghc/ghc/-/issues/23188 and https://github.com/haskell/cabal/issues/8882

On the GHC side, it seems like we should have been more careful in introducing this change, and the impact was not anticipated fully by Cheng when he made the patch. It is possible that we could narrow the scope of this patch to wasm for the 9.6 series (which you should advocate for on the ticket if you think that's the best path forward).

I have added a test to the bindist install tests which test installing on aarch64-darwin with a brew based toolchain and added a particular test which fails with a brew toolchain (but not the system toolchain).

So the best thing to do for now seems to be to use the system toolchain to build binaries (unless there is a particular other reason to use the toolchain provided by homebrew).

[hasufell]

Thanks for the investigation!

[TerrorJack]

@mpickering I don't have time to push forwards a proper Cabal fix, though I did put up https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12548 at your convenience. Sorry for the breakage :/

[hasufell]

Most things work now, except FreeBSD built binaries still crash: https://gitlab.haskell.org/ghc/ghc/-/issues/24672

ghcup: internal error: Ticker: read(timerfd) failed with Operation not supported and returned -1
    (GHC version 9.6.5 for x86_64_portbld_freebsd)
    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
ghcup: user error (No such PID 79566)

[hseg]

In trying to rebase this onto v0.1.30.0, I've noticed that you checked in .orig files. Was this intended?

[hasufell]

I've noticed that you checked in .orig files. Was this intended?

No

[hseg]

OK, I finally finished rebasing. I pushed a branch in https://github.com/hseg/ghcup-hs/tree/rebased-ghc-9.6, it builds with all tests passing against lts-22.33. I've made some guesses as to how the freezefiles needed to be updated, and I can only test on Arch Linux, so I'd appreciate a CI run to sanity-check.

[hseg]

btw, note my comment in https://github.com/haskell/ghcup-hs/pull/1123#issuecomment-2341428651 -- I think there may be some stale references in the docs

[hasufell]

Can you provide a PR?

[hasufell]

superseded by https://github.com/haskell/ghcup-hs/pull/1132