Fix #6160 Move Stack on to GHC 9.4.6

[mpilgrem]

Does not yet address any changes to *.md files. Relying on CI.

EDIT: I have bumped the ambition from GHC 9.4.5 to GHC 9.4.6, because (a) the latter is now available via Stackage LTS Haskell 21.8 and (b) @benz0li has a Docker image for GHC 9.4.6 that includes Stack 2.11.1.

[mpilgrem]

See issue #6160.

[mpilgrem]

@psibi, please could you prepare and publish a GHC 9.4.5 docker image to replace the current repo: fpco/alpine-haskell-stack:9.2.7?

[mpilgrem]

On Windows only, the three integration tests that use repl [] action (3926, 4270, module-added-multiple-times) are behaving differently with nightly-2023-06-18 (GHC 9.4.5) than they did with lts-20.23 (GHC 9.2.7). They are behaving as if stack repl is encountering an EOF (and quitting with Leaving GHCi., which is captured) before any GHCi command is received.

[mpilgrem]

@psibi, thanks for the Alpine Docker images. Those builds are failing, during the 'preprocessing library' step for certain packages only - zlib, unix-compat, old-time, network, lukko, hinotify, filelock, digest, clock, basement. The pattern is the same in the case of each package. Taking clock as an example:

2023-06-19T17:59:31.4758655Z clock> configure
2023-06-19T17:59:32.1235205Z clock> Configuring clock-0.8.3...
2023-06-19T17:59:32.3592989Z clock> build
2023-06-19T17:59:32.4102225Z clock> Preprocessing library for clock-0.8.3..
2023-06-19T17:59:32.6679250Z clock> running .stack-work/dist/x86_64-linux-dkbbc7701fbbddb5591b4899472412e28d/Cabal-3.8.1.0/build/System/Clock_hsc_make failed (exit code -11)
2023-06-19T17:59:32.6680070Z clock> rsp file was: ".stack-work/dist/x86_64-linux-dkbbc7701fbbddb5591b4899472412e28d/Cabal-3.8.1.0/build/System/hsc2hscall5472-3.rsp"
2023-06-19T17:59:32.6683856Z clock> output file:".stack-work/dist/x86_64-linux-dkbbc7701fbbddb5591b4899472412e28d/Cabal-3.8.1.0/build/System/Clock.hs"
2023-06-19T17:59:32.6684780Z clock> command was: .stack-work/dist/x86_64-linux-dkbbc7701fbbddb5591b4899472412e28d/Cabal-3.8.1.0/build/System/Clock_hsc_make  >.stack-work/dist/x86_64-linux-dkbbc7701fbbddb5591b4899472412e28d/Cabal-3.8.1.0/build/System/Clock.hs
2023-06-19T17:59:32.6685257Z clock> error:

Clock_hsc_make is the executable that GHC compiles from the C code produced by hsc2hs - the executable that is intended to output Haskell code.

Frustratingly, the final error: is not followed by an error in the CI logs. I think - but am not sure - that (exit code -11) may mean a segmentation fault.

I think what those packages may have in common is an *.hsc file. In the case of clock it is System/Clock.hsc. Is there anything about the Alpine images that may be stopping the *_hsc_make from working?

[psibi]

@mpilgrem Sorry, I would be too occupied for this and most like couple of next weeks to devote time to this issue and debug it myself.

Regarding debugging, I would try to use the docker image and compile a smaller project and see how it goes.

[mpilgrem]

@psibi, noted and understood. I am currently experimenting locally with Alpine Linux on WSL2. My current hypothesis is that the underlying problem may be GHC 9.4.5 on Alpine Linux (https://gitlab.haskell.org/ghc/ghc/-/issues/23043#note_506034) or Alpine Linux 3.18.2 (released on 2023-06-14).

[psibi]

@mpilgrem Good point, if you want me to make another image on a different alpine - let me know. That shouldn't take too much time from my side.

[mpilgrem]

Not yet reflected in the CI results to date, because the CI does not yet reach that point, Stack will not build with GHC 9.4.5 on Alpine Linux/x86_64 due to a bug in GHC/template-haskell. See https://gitlab.haskell.org/ghc/ghc/-/issues/23043#note_506034.

[mpilgrem]

I have a set up a small, temporary, test repository for the Docker/Alpine Linux/GHC 9.4.5/hsc2hs/segmentation fault problem at: https://github.com/mpilgrem/alpine-haskell-stack-test. Works with repo: fpco/alpine-haskell-stack:9.2.7, fails with ghcr.io/fpco/alpine-haskell-stack:9.4.5. Alpine Linux/GHC 9.4.5/hsc2hs works locally (that is, outside of Docker) (on WSL2). What has changed?

1. The starting point: was SHA e2e16842c9b54d985bf1ef9242a313f36b856181f188de21313820e177002501 (alpine (Docker Official Image), 3.17.2, linux/amd64); now 25fad2a32ad1f6f510e528448ae1ec69a28ef81916a004d3629874104f8a7f70 (3.18.2, linux/amd64).
2. The contents included pkgsMusl.haskell.compiler.ghc927 from NixOS/nixpkgs@81d5cb1; now pkgs.pkgsMusl.haskell.compiler.ghc945 from NixOS/nixpkgs@989a2b9.
3. The stack executable added was https://github.com/commercialhaskell/stack/releases/download/v2.9.3/stack-2.9.3-linux-x86_64-bin; now is https://github.com/commercialhaskell/stack/releases/download/v2.11.1/stack-2.11.1-linux-x86_64-bin.

I think it is unlikely to be Alpine Linux 3.17.2 -> 3.18.2, because if it was giving rise to segmentation faults in Docker generally, I would expect to see that surface on the Internet quickly (even if it only recently released).

I think it is not Stack 2.9.3 -> 2.11.1, because of when the segmentation fault occurs.

My guess for the culprit is the NixOS/nixpkgs build of GHC 9.4.5. The README at https://github.com/fpco/alpine-haskell-stack states that it differs from the 'official' Alpine Linux binary released by the GHC developers (and it is the 'official' binary that I am using locally).

[mpilgrem]

@psibi, to test my hypothesis in the comment above - about the problem being with the NixOS/nixpkgs build of GHC 9.4.5 - would it be possible to create a further Docker image that uses, instead, the 'official' Alpine Linux version of GHC 9.4.5 at https://downloads.haskell.org/~ghc/9.4.5/ghc-9.4.5-x86_64-alpine3_12-linux-static-int_native.tar.xz?

[mbj]

I'm running GHC 9.4.5 in production on alpine. And I've experienced the same issue, TH related crashes. The official bindists from hackage.org seem to be affected, and I suspect these are from producing the GHC from an older alpine version. The gitlab CI is using an alpine release a few alpine versions behind.

What worked for me was using a self compiled GHC (via hadrian, I never understood the make system).

[psibi]

@mpilgrem

to test my hypothesis in the comment above - about the problem being with the NixOS/nixpkgs build of GHC 9.4.5 - would it be possible to create a further Docker image that uses, instead, the 'official' Alpine Linux version of GHC 9.4.5 at

Sorry, it took a while to get back to you on this. The original reason why we are not using the official alpine version released by the GHC team were:

• The base alpine image was old. (Not a big concern)
• The stack codebase when built using that GHC, segfaults during the compilation journey. Ideally, I should have reported it to the GHC team - but I couldn't create a small enough reproducible codebase and my work on stack was/is quite limited.

Maybe, it has been fixed in the recent releases. I will see if I can create another image in the upcoming days to make it easier for you - but creating image based on official ghc alpine is pretty trivial as compared to the nix route that I'm currently doing.

[mbj]

@psibi, @mpilgrem This reproduction triggers it for me under the official GHC 9.4.5 bindists: https://gitlab.haskell.org/ghc/ghc/-/issues/20266#note_440518

[benz0li]

You could try the multi-arch (linux/amd64, linux/arm64/v8) glcr.b-data.ch/ghc/ghc-musl:9.4.6 image.

Cross reference: #6142 (comment)