lsupg Static Builds With GHC 9
The GHC team distributes
Alpine Linux builds that can
be used for static
compilation. I use these “bindists” to build static lsupg
executables, which must be static so that they can run in a wide range
of different Linux environments, using ghc-musl
containers. I recently updated the lsupg
project to use the
most recent major version of GHC, and some builds fail. This morning, I
checked which versions build and which fail.
GHC 9.0.2 | GHC 9.2.5 | GHC 9.4.4 | |
---|---|---|---|
Cabal | 29,021,968 | FAIL | 32,082,168 |
Stack (external) | 28,665,056 | FAIL | FAIL |
Stack (internal) | 28,665,008 | FAIL | FAIL |
ghci | OK | FAIL | FAIL |
For each version, I tried building using Cabal as well as Stack. I tried building using
Stack outside the container with the --docker
option (“external”) as well as using Stack inside the container
(“internal”). In the above table, the numbers are the size of the static
executables in bytes when builds succeed. I also tried running
ghci
, which has been broken since GHC 9.2, as described in
the GHC 9.2
Alpine Segmentation Fault blog post.
All builds using GHC 9.0.2 succeed, while all builds using GHC 9.2.5 fail. The Alpine segfaults many tests in 9.2.1 issue is likely related. Interestingly, GHC 9.4.4 builds succeed when using Cabal but fail when using Stack, even though the exact same bindist is used!
Note that a very simply example
program is built and tested when building new ghc-musl
images. It is interesting that these tests pass while lsupg
builds fail, as lsupg
is not very complicated. Some errors
mention GMP, so perhaps updating the
example program to include an Integer
would cause it to
fail as well. I might investigate this if I can find the time.
Speaking of GMP, the GHC team also provides Alpine bindists that use a Haskell-native bignum implementation instead of GMP. Perhaps building with this implementation would succeed… I might investigate this if I can find the time.
Unfortunately, ghci
is still broken in the latest
releases. There is a ghci
segmentation fault on alpine:3.15 with GHC 9.2.4 issue that
indicates that CI tests using Alpine
3.12 pass, so it may only be broken on newer releases of Alpine. I
would like to test this now.
I created GHC 9.2.5 and GHC 9.4.4 images using Alpine 3.12 using the following commands, but I still get failures.
$ earthly \
--allow-privileged \
--build-arg BASE_TAG=ghc-musl: \
--build-arg ALPINE_VERSION=3.12 \
+ghc925
$ earthly \
--allow-privileged \
--build-arg BASE_TAG=ghc-musl: \
--build-arg ALPINE_VERSION=3.12 \
+ghc944
That is all the time I have today, but I hope to find time to create a minimal test and experiment with the Haskell-native bignum implementation soon.