benz0li / ghc-musl Goto Github PK

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

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.

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).

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