Bring back statically linked stack binaries

[nh2]

As explained on #4087, and partially on #2387, we lost static stack binaries for Stack 1.7 due to Alpine Linux not supporting GHC 8.2.

Not having static stack creates a couple of problems:

• stack --docker is broken if the docker image and the host machine have incompatible glibc versions (Dynamically linked stack release binaries aren't really compatible with stack --docker #4087).
• we don't have official support for some Linux distributions (e.g. Alpine itself, Support musl-based Linux distributions like Alpine Linux #2387)
• reduced shelf life for stack releases, and more release management effort, as the current ones will stop working when Linux distributions update their glibc, libz etc

This issue tracks getting static stack back.

[mitchty]

Note, Alpine Linux 3.8 will have 8.4.3, but only for x86_64 right now. alpinelinux/aports#4255

[nh2]

Here's another way I just got to work: https://github.com/nh2/static-haskell-nix/blob/master/static-stack

That's one command to build a fully static stack (1.6.5 as of writing) with nix's musl toolchain.

[dbaynard]

Just reading the description of #4087 is concerning; the alpine linux build process seems quite ad-hoc and fragile. I'm not sure how the project leads go about new releases, but given stack itself has nix support, it would make sense for static builds to be produced using nix.

I'd like to recommend using nix for building releases, replacing alpine linux. Is your static-stack project suitable for that?

[borsboom]

I'd like to recommend using nix for building releases, replacing alpine linux. Is your static-stack project suitable for that?

Agreed, if there was a way to use stack --nix with this I'd be all for switching to it as the standard way to build static binaries.

[mitchty]

@dbaynard its.... not all it could be, restrictions like no network access, not being able to build a subpackage with a different version, and other things greatly make packaging harder than it really need be.

That and I've literally spent the past 3 months on and off trying to get the cross compilation to work to no avail is making me wonder how much effort I should spend in that regard if I can just use nix.

[borsboom]

@mitchty What about just a GHC bindist that can be installed on Alpine (or documented process for building a working GHC from source), rather than trying to make an APK package?

[mitchty]

@borsboom That wouldn't be too hard to do, would also generally solve #2387 as well.

Would it be better to get "official" support for alpine linux so that we get official bindists? Otherwise we end up where I was prior to upstreaming ghc to alpine linux community, aka: who do we trust to build/host etc...

[borsboom]

Would it be better to get "official" support for alpine linux so that we get official bindists?

Yes, that would be awesome.

[nh2]

Agreed, if there was a way to use stack --nix with this I'd be all for switching to it as the standard way to build static binaries.

This may be possible, I just haven't tried it yet. At least in theory, supplying a musl-supported --system-ghc with stack --nix and have stack use that should work fine.

[dbaynard]

It would be good to have a static version of 1.8 when that is ready for release

[nh2]

This was done with v1.9.1, using https://github.com/nh2/static-haskell-nix/blob/master/static-stack as described above.

[dtzWill]

\o/

…

On Fri, 07 Dec 2018 14:48:36 -0800, Niklas Hambüchen ***@***.***> wrote: Closed #4088. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #4088 (comment) part: text/html

[chespinoza]

Is there a way to do this without nix?

[nh2]

@chespinoza There may be one if you manage to compile Stack on Alpine.

Why are you looking for one?