Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support GHC-9.6 wrt #979 #997

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Support GHC-9.6 wrt #979 #997

wants to merge 5 commits into from

Conversation

hasufell
Copy link
Member

@hasufell hasufell commented Feb 2, 2024 •
edited

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

@hasufell hasufell force-pushed the ghc-9.6 branch 8 times, most recently from eb5e3a0 to ca2880f Compare April 15, 2024 08:54
@mpickering
Copy link

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: pyenv/pyenv#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
Copy link

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
Copy link
Member Author

@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
Copy link

@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
Copy link
Member Author

Streamly is broken for us:

@hasufell
Copy link
Member Author

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 hasufell force-pushed the ghc-9.6 branch 2 times, most recently from 0d8a9ed to f5298c5 Compare April 30, 2024 11:31
@hasufell
Copy link
Member Author

@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
Copy link

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 haskell/cabal#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
Copy link
Member Author

hasufell commented May 2, 2024

Thanks for the investigation!

@TerrorJack
Copy link
Contributor

@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
Copy link
Member Author

hasufell commented May 18, 2024 •
edited

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)

@hasufell hasufell mentioned this pull request Jun 1, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@hasufell @mpickering @TerrorJack