Description
Summary
stack --docker doesn't work reliably across Linux distributions because stack is no longer statically linked.
Why we don't have statically linked executables at the moment
In the past, we provided statically linked stack executables. Those worked fine with stack --docker.
We used Alpine Linux to create these stack executables. Unforunately, Alpine Linux doesn't work with GHC >= 8.2 (see #2387, channable/vaultenv#43 (comment), and alpinelinux/aports#4255).
Stack 1.7 requires GHC >= 8.2. So we don't have staically linked executables for that.
We needed Alpine Linux to create the executables because it provided a full musl based toolchain (musl is a replacement for glibc, and glibc pretty much forbids static linking)
Why static linking is needed for stack --docker to work
When you use stack --docker build, the outer stack executable is re-executed inside the docker container.
If that executable is dynamically linked, and the outer libc is a different version than the inner libc, then stack will fail to run in the container.
Right now, the linked-dynamicall-against-libc generic stack installer we provide works on many Linux distributions, and it works in docker images such as fpco/stack-build:lts-11.13 which is what stack docker pull pulls.
But it doesn't work on all distributions, and for those where it doesn't, stack --docker support is completely broken right now. Further, as soon as some distro (like Arch) will advance to an incompatible libc earlier than other distros (e.g. Ubuntu), the generic installer will also stop working nicely.
How it fails
It doesn't fail with a nice error message, leaving the user in doubt:
$ stack --docker build
Received ExitFailure 127 when running
Proposed solution
We need to
- get statically linked
stackback in order to makestack --dockerwork everywhere. - tell people that dynamically-linked
stackdoesn't really supportstack --docker.- in a message during
stackexecution so that users don't get confused by the nonexisting error message (see above) - in documentation; downstream packagers don't seem to know that they break
stack --dockerwhen they link stack fully dynamically (see my next comment for how Arch Linux gets it wrong) - EDIT: not necessary, as stack has an automatic fallback to downloading static executables if re-executing the host
stack --versioninside Docker doesn't work, see Dynamically linked stack release binaries aren't really compatible with stack --docker #4087 (comment)
- in a message during
- improve the docs saying
executable must be built on linux-x86_64 and statically linked(see comment below)
Scope
This ticket is specifically for stack --docker problems; I'll file a separate issue (#4088) about getting statically linked stack back, as that is desiable also for other reasons than Docker.