Binary for 64-bit (aarch64) Alpine Linux

[benz0li]

If you used my multi-arch (linux/amd64, linux/arm64/v8) glcr.b-data.ch/ghc/ghc-musl docker image to build Stack, you could provide statically linked binaries for both architectures.

[benz0li]

Tested with glcr.b-data.ch/ghc/ghc-musl:9.2.7 (both archs):

On a machine with docker-ce installed:

docker run --rm -ti glcr.b-data.ch/ghc/ghc-musl:9.2.7 bash

Inside the container:

Install Cabal (the tool) v3.8.1.0

cabal update
cabal install cabal-install-3.8.1.0
cp -aL /root/.cabal/bin/cabal /usr/bin

Clone the repository

cd /tmp
git clone https://github.com/commercialhaskell/stack.git
cd stack

Checkout, patch and build:

git checkout v2.11.1
sed -i /stack/d cabal.config
cabal build --allow-older --enable-executable-static --ghc-option=-optl=-pthread

Strip binary:

strip $(find dist-newstyle -name stack -type f)

---

Result: Statically linked and stripped stack executable.

$ file $(find dist-newstyle -name stack -type f)
dist-newstyle/build/aarch64-linux/ghc-9.2.7/stack-2.11.1/build/stack/stack: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped

$ $(find dist-newstyle -name stack -type f) --version
Version 2.11.1, Git revision c1167a6abc3f4978ccded5ba0246a57387da0e2f (dirty) (9638 commits) aarch64
Compiled with:
- Cabal-3.8.1.0
- Cabal-syntax-3.8.1.0
- Glob-0.10.2
- OneTuple-0.3.1
- QuickCheck-2.14.2
- StateVar-1.2.2
- aeson-2.0.3.0
- annotated-wl-pprint-0.7.0
- ansi-terminal-0.11.4
- ansi-wl-pprint-0.6.9
- appar-0.1.8
- array-0.5.4.0
- asn1-encoding-0.9.6
- asn1-parse-0.9.5
- asn1-types-0.3.4
- assoc-1.0.2
- async-2.2.4
- attoparsec-0.14.4
- attoparsec-0.14.4
- attoparsec-iso8601-1.0.2.1
- auto-update-0.1.6
- base-4.16.4.0
- base-compat-0.12.2
- base-compat-batteries-0.12.2
- base-orphans-0.8.8.2
- base16-bytestring-1.0.2.0
- base64-bytestring-1.2.1.0
- basement-0.0.15
- bifunctors-5.5.15
- binary-0.8.9.0
- blaze-builder-0.4.2.2
- blaze-html-0.9.1.2
- blaze-markup-0.8.2.8
- byteorder-1.0.4
- bytestring-0.11.4.0
- casa-client-0.0.1
- casa-types-0.0.2
- case-insensitive-1.2.1.0
- cereal-0.5.8.3
- clock-0.8.3
- colour-2.3.6
- comonad-5.0.8
- conduit-1.3.4.3
- conduit-combinators-1.3.0
- conduit-extra-1.3.6
- connection-0.3.1
- containers-0.6.5.1
- contravariant-1.5.5
- cookie-0.4.6
- cryptohash-sha256-0.11.102.1
- cryptonite-0.30
- cryptonite-conduit-0.2.2
- data-array-byte-0.1.0.1
- data-default-class-0.1.2.0
- data-fix-0.3.2
- deepseq-1.4.6.1
- digest-0.0.1.7
- directory-1.3.6.2
- distributive-0.6.2.1
- dlist-1.0
- easy-file-0.2.3
- echo-0.1.4
- ed25519-0.0.5.0
- exceptions-0.10.4
- extra-1.7.13
- fast-logger-3.1.2
- file-embed-0.0.15.0
- filelock-0.1.1.5
- filepath-1.4.2.2
- fsnotify-0.4.1.0
- generic-deriving-1.14.3
- ghc-bignum-1.2
- ghc-boot-th-9.2.7
- ghc-prim-0.8.0
- githash-0.1.6.3
- hackage-security-0.6.2.3
- hashable-1.4.2.0
- hi-file-parser-0.1.3.0
- hinotify-0.4.1
- hourglass-0.2.12
- hpack-0.35.2
- hpc-0.6.1.0
- http-api-data-0.4.3
- http-client-0.7.13.1
- http-client-tls-0.3.6.1
- http-conduit-2.3.8
- http-download-0.2.0.0
- http-types-0.12.3
- indexed-traversable-0.1.2.1
- indexed-traversable-instances-0.1.1.2
- infer-license-0.2.0
- integer-gmp-1.1
- integer-logarithms-1.0.3.1
- iproute-1.7.12
- libyaml-0.1.2
- lift-type-0.1.1.1
- lifted-base-0.2.3.12
- lukko-0.1.1.3
- megaparsec-9.2.2
- memory-0.17.0
- microlens-0.4.12.0
- microlens-mtl-0.2.0.3
- microlens-th-0.4.3.11
- mime-types-0.1.0.9
- mintty-0.1.4
- monad-control-1.0.3.1
- monad-logger-0.3.39
- monad-loops-0.4.3
- mono-traversable-1.0.15.3
- mtl-2.2.2
- mtl-compat-0.2.2
- mustache-2.4.1
- neat-interpolation-0.5.1.3
- network-3.1.2.8
- network-uri-2.6.4.2
- old-locale-1.0.0.7
- old-time-1.1.0.3
- open-browser-0.2.1.0
- optparse-applicative-0.17.0.0
- optparse-simple-0.1.1.4
- pantry-0.8.2.1
- parsec-3.1.15.0
- parser-combinators-1.3.0
- path-0.9.2
- path-io-1.7.0
- path-pieces-0.2.1
- pem-0.2.4
- persistent-2.14.5.0
- persistent-sqlite-2.13.1.1
- persistent-template-2.12.0.0
- pretty-1.1.3.6
- primitive-0.7.3.0
- process-1.6.16.0
- project-template-0.2.1.0
- random-1.2.1.1
- resource-pool-0.2.3.2
- resourcet-1.2.6
- retry-0.9.3.0
- rio-0.1.22.0
- rio-orphans-0.1.2.0
- rio-prettyprint-0.1.4.0
- rts-1.0.2
- safe-0.3.19
- safe-exceptions-0.1.7.3
- scientific-0.3.7.0
- semialign-1.2.0.1
- semigroupoids-5.3.7
- semigroups-0.20
- silently-1.2.5.3
- socks-0.6.1
- split-0.2.3.5
- splitmix-0.1.0.4
- stm-2.5.0.2
- stm-chans-3.0.0.9
- streaming-commons-0.2.2.5
- strict-0.4.0.1
- syb-0.7.2.3
- tagged-0.8.6.1
- tar-0.5.1.1
- tar-conduit-0.3.2
- template-haskell-2.18.0.0
- temporary-1.3
- text-1.2.5.0
- text-metrics-0.3.2
- text-short-0.1.5
- th-abstraction-0.4.5.0
- th-compat-0.1.4
- th-expand-syns-0.4.11.0
- th-lift-0.8.3
- th-lift-instances-0.1.20
- th-reify-many-0.1.10
- these-1.1.1.1
- time-1.11.1.1
- time-compat-1.9.6.1
- tls-1.5.8
- transformers-0.5.6.2
- transformers-base-0.4.6
- transformers-compat-0.7.2
- typed-process-0.2.11.0
- unicode-data-0.3.1
- unicode-transforms-0.4.0.1
- unix-2.7.2.2
- unix-compat-0.5.4
- unix-time-0.4.9
- unliftio-0.2.24.0
- unliftio-core-0.2.1.0
- unordered-containers-0.2.19.1
- uuid-types-1.0.5
- vault-0.3.1.5
- vector-0.12.3.1
- vector-algorithms-0.8.0.4
- witherable-0.4.2
- x509-1.7.7
- x509-store-1.6.9
- x509-system-1.6.7
- x509-validation-1.6.12
- yaml-0.11.11.0
- zip-archive-0.4.3
- zlib-0.6.3.0

Warning: this is an unsupported build that may use different versions of
dependencies and GHC than the officially released binaries, and therefore may
not behave identically.  If you encounter problems, please try the latest
official build by running 'stack upgrade --force-download'.

[mpilgrem]

@benz0li, as a Windows user, I am probably not understanding the significance of your suggestion - this repository already provides Stack executables for Linux/x86_64 and Linux/AArch64 (I understand that AMD64 is another term for x86_64 and that ARM64 is another term for AArch64). Can you explain futher for me?

[hasufell]

I can't follow either. There are no GHC bindists for aarch64 musl. What's the point?

[benz0li]

I can't follow either. There are no GHC bindists for aarch64 musl. What's the point?

@hasufell There is https://github.com/benz0li/ghc-musl:

• os/arch's: linux/amd64, linux/arm64/v8
• Built using Hadrian, from source, without docs

ℹ️ The multi-arch (linux/amd64, linux/arm64/v8) docker image used to build the Linux amd64 and arm64 binary releases of pandoc.

[hasufell]

Where exactly are the bindists? Stack needs URLs to GHC bindists. Docker images are not enough.

[benz0li]

Stack needs URLs to GHC bindists. Docker images are not enough.

@hasufell I was not aware of that. Thanks for pointing that out.

[benz0li]

Where exactly are the bindists?

@hasufell I am happy provide current bindists if that helps the process of providing official Linux (AArch64) Alpine releases of GHC.

FYI @bgamari

[hasufell]

@benz0li that might be a stopgap, but I'm personally not a fan of using 3rd party bindists. @mpilgrem might have a different opinion on this.

GHCup currently only uses either upstream bindists or bindists I built myself. That is a small attack surface.

The other controversial thing about 3rd party bindists is that they usually don't run the testsuite, because it's really hard to support that. But that's only a minor issue in my opinion (GHC test suite should run on the end users system anyway, not the build machine).

The trust issue could partly be solved by building the unofficial GHC bindists in a proper CI that the end user can verify, but that would be a lot more work.

Either way, uploading the bindists to a permanent public storage is definitely valuable, no matter if or how tools use them.

[benz0li]

@benz0li that might be a stopgap, but I'm personally not a fan of using 3rd party bindists. [...]

Me neither 😉.

Maintaining https://github.com/benz0li/ghc-musl is quite some work and currently serves one purpose only: Building statically linked Pandoc binary releases for both Linux/x86_64 and Linux/AArch64.

GHCup currently only uses either upstream bindists or bindists I built myself. That is a small attack surface.

This is how it should be done.

The other controversial thing about 3rd party bindists is that they usually don't run the testsuite, because it's really hard to support that. [...]

Correct; The testsuite is not run.

The trust issue could partly be solved by building the unofficial GHC bindists in a proper CI that the end user can verify, but that would be a lot more work.

Is this proper enough? https://gitlab.b-data.ch/ghc/ghc-musl/-/pipelines

Either way, uploading the bindists to a permanent public storage is definitely valuable, no matter if or how tools use them.

I might do that in the future by adding releases to GitLab CI.