GHC 9.6.3 is not in the Version Matrix but is now supported by nightly-2023-10-01.

GHC 9.6.3 has an 'official' Alpine Linux/x86_64 version (dynamically linked) that, I think, is free of the problems that trouble the statically-linked versions for that platform.

Also, Stack 2.13.1 has been released. All of its 'official' Linux binary distributions are now statically linked.

E.g. for docker build -t ghc-musl:8.8.4 -f prior/8.8.4.Dockerfile .

Modification:

diff --git a/latest.Dockerfile b/latest.Dockerfile
index 0b90abe..3c97655 100644
--- a/latest.Dockerfile
+++ b/latest.Dockerfile
@@ -5,7 +5,7 @@ ARG STACK_VERSION
 ARG GHC_VERSION_BUILD=${GHC_VERSION}
 ARG CABAL_VERSION_BUILD=${CABAL_VERSION}
 
-FROM glcr.b-data.ch/ghc/ghc-musl:9.6.5 as bootstrap
+FROM glcr.b-data.ch/ghc/ghc-musl:9.8.2 as bootstrap
 
 RUN apk upgrade --no-cache \
   && apk add --no-cache \
@@ -36,9 +36,9 @@ RUN cd /tmp \
   && curl -sSLO https://downloads.haskell.org/~ghc/"$GHC_VERSION"/ghc-"$GHC_VERSION"-src.tar.xz \
   && curl -sSLO https://downloads.haskell.org/~ghc/"$GHC_VERSION"/ghc-"$GHC_VERSION"-src.tar.xz.sig \
   && gpg --keyserver hkps://keyserver.ubuntu.com:443 \
-    --receive-keys 88B57FCF7DB53B4DB3BFA4B1588764FBE22D19C4 || \
+    --receive-keys FFEB7CE81E16A36B3E2DED6F2DE04D4E97DB64AD || \
     gpg --keyserver hkp://keyserver.ubuntu.com:80 \
-    --receive-keys 88B57FCF7DB53B4DB3BFA4B1588764FBE22D19C4 \
+    --receive-keys FFEB7CE81E16A36B3E2DED6F2DE04D4E97DB64AD \
   && gpg --verify "ghc-$GHC_VERSION-src.tar.xz.sig" "ghc-$GHC_VERSION-src.tar.xz" \
   && tar -xJf "ghc-$GHC_VERSION-src.tar.xz" \
   && cd "ghc-$GHC_VERSION" \

Build:

docker build \
  --build-arg GHC_VERSION=9.10.1 \
  --build-arg CABAL_VERSION=3.10.3.0 \
  --build-arg STACK_VERSION=2.15.7 \
  -t ghc-musl \
  -f latest.Dockerfile .

Error:

134.4 Error: hadrian: The program 'alex' is required but it could not be found.
134.4 
134.4 ExitFailure 1
134.4 Build failed.

@bgamari Why is alex required now?

Error message:

No compiler found, expected minor version match with ghc-9.2.8 (aarch64) (based on resolver setting in /<example>/stack.yaml).
To install the correct GHC into /root/.stack/programs/aarch64-linux/, try running 'stack setup' or use the '--install-ghc' flag. To use your system GHC installation, run 'stack config set system-ghc --global true', or use the '--system-ghc' flag.

Firstly, thanks for maintaining this project. I wondered if you'd be able to help debug a build issue when using the GHC 9.4.5 container, or suggest something we could try.

We're trying to use ghc-musl to produce static builds for the juvix project but are experiencing a linker issue with the build.

We're using ghc-musl:9.4.5 on x86_64.

The build works with a standard (i.e distributed by GHC) distribution of GHC 9.4.5.

Reproduction steps

• I used the following script to do the build build.sh.gz
  • The stack command is stack install --allow-different-user --system-ghc --ghc-options='-static -split-sections -optl-static'
  • We link against a static runtime library that we build using clang
• I launched the container using docker run -v $PWD/build.sh:/build.sh --rm -ti glcr.b-data.ch/ghc/ghc-musl:9.4.5 /bin/bash
• The resulting transcript of the build session: typescript.gz (after gzip -d this is best viewed using less because of recorded ANSI escapes).

Linker error during build

/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/crtbe
ginT.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

<no location info>: error:
    `gcc' failed in phase `Linker'. (Exit code: 1)

Upstream issue?

I found this issue which is related https://gitlab.haskell.org/ghc/ghc/-/issues/20168. The solution given there is to configure GHC to use its internal linker (used by ghci). However this does not seem like an ideal solution, we should use the system linker for this (as noted in the GHC documentation, the internal linker has known bugs, and they'd like to remove it).

ghc 9.6.5 and stack 2.15.7 are out. Could you please build image for them? Latest stackage lts is already using ghc 9.6.5.

Currently, stack must be installed manually (linux/amd64 image) or even built manually (linux/arm64/v8 image).

It would be convenient if stack was already available in the image.

The compiled GHC tarball is stored in an intermediate layer in/tmp before extracted and deleted. Therefore, the size of the tarball (roughly 200MB) still counts to the size of final image, and made the image significantly larger and difficult to fetch. See

To shrink the size of final docker image, we could

• Squash the final image, with something like

FROM scratch
COPY --from=ghc-stage1 / /
COPY --from=ghc-stage2 /root/.local/bin/cabal /usr/local/bin/cabal
CMD ["ghci"]

• use COPY --link for tarball copying