Use GHC docker images from benz0li / ghc-musl to build linux binaries #2166
Comments
|
@paulcadman Please test first and ping me if something does not work as expected. Be aware of the following:
|
|
Regarding Stack see issue commercialhaskell/stack#6141. ℹ️ An unsupported, statically linked binary of Stack has been added to The unsupported binary in the |
|
|
|
Thanks for the help @benz0li , and for maintaining these Docker containers! |
|
I hope that there will be proper GHC bindists for Linux (AArch64) Alpine releases some time in the future. Cross reference: commercialhaskell/stack#6142 |
|
@paulcadman I am thinking of including Cross reference: benz0li/ghc-musl#2 |
Stack LTS 21.6 uses GHC 9.4.5, binaries for HLS are available via ghcup.
Changes required:
1. Fix warnings about type level `:` and `[]` used without backticks.
2. Fix warnings about deprecation of builtin `~` - replaced with `import
Data.Type.Equality ( type (~) )` in the Prelude
3. SemVer is no longer a monoid
4. `path-io` now contains the `AnyPath` instances we were defining
(thanks to Jan) so they can be removed.
5. Added `aeson-better-errors-0.9.1.1` as an extra-dep. The reason it is
not part of the resolver is only because it has a strict bound on base
which is not compatible with ghc 9.4.5. To work around this I've set:
```
allow-newer: true
allow-newer-deps:
- aeson-better-errors
```
which relaxed the upper constraint bounds for `aeson-better-errors`
only. When the base constraints have been updated we can remove this
workaround.
6. Use stack2cabal to generate the cabal.project file and to freeze
dependency versions.
https://www.stackage.org/lts-21.6/cabal.config now contains the
constraint `haskeline installed`, which means that the version of
haskeline that is globally installed with GHC 9.4.5 will be used, see:
* commercialhaskell/stackage#7002
GHC 9.4.5 comes with haskeline 0.8.2 preinstalled but our configuration
contains the source-repository-package for haskeline 0.8.2.1 (required
because we're using a fork) so if you try to run` cabal build` you get a
conflict.
Constraints from cabal imports cannot yet be overridden so it's not
possible to get rid of this conflict using the import method. So we need
to use stack2cabal with an explicit freeze file instead.
7. Remove `runTempFilePure` as this is unused and depends on
`Polysemy.Fresh` in `polysemy-zoo` which is not available in the
resolver. It turns out that it's not possible to use the `Fresh` effect
in a pure context anyway, so it was not possible to use
`runTempFilePure` for its original purpose.
8. We now use https://github.com/benz0li/ghc-musl as the base container
for static linux builds, this means we don't need to maintain our own
Docker container for this purpose.
9. The PR for the nightly builds is ready
anoma/juvix-nightly-builds#2, it should be
merged as soon as this PR is merged.
Thanks to @benz0li for maintaining https://github.com/benz0li/ghc-musl
and (along with @TravisCardwell) for help with building the static
binary.
* Closes #2166
We currently build our own GHC Docker images for alpine linux to produce the statically linked binaries for linux. (As a reminder we do this rather than use the GHC published binaries because of https://gitlab.haskell.org/ghc/ghc/-/issues/20266)
I've found a project which does the same thing as us and produces public Docker containers: https://github.com/benz0li/ghc-musl. These containers are used to build the pandoc releases.
We should switch to using these.
As a bonus they build aarch64 images so we could start publishing linux-aarch64 juvix binaries too (the blocker for this is the availability of aarch64, musl compatible stack releases) .
The text was updated successfully, but these errors were encountered: