Fully static Haskell executables - overview issue

[nh2]

If you just want to build static Haskell executables right now, follow these instructions.

This issue collects/links all issues and ongoing work to make fully-static building of Haskell executables an excellently-working feature in nixpkgs.

I will update here regularly the progress we are making, and sub-goals we encounter on the way that need to be fulfilled to tick off the parent goal.

Obviously contributions to this list are welcome.

• Fully static builds of Haskell exes should be trivial (end goal)
  • Document in the nixpkgs manual how to make fully static Haskell builds
  • Building stack based projects with their own resolver should be really easy
    • Done since Fully static Haskell executables - overview issue #43795 (comment)
    • A minimal stack based example should be added (here)
  • All Most Haskell executables in nixpkgs succeed to build statically
    • This is being worked on in the survey directory of https://github.com/nh2/static-haskell-nix
    • Build as many static Haskell executables from nixpkgs as possible
      • Build nix expression that can find and build all Haskell executables in nixpkgs Stackage
        • Build parser for configuration-hackage2nix.yaml to be able to filter for Stackage packages (thanks @domenkozar for the tip)
      • We are restricting ourselves executables on Stackage here because we know those should build.
    • Some specific large Haskell projects succeed to build statically
      • stack
        • stack builds with crossSystem = { config = "x86_64-unknown-linux-musl"; };
        • stack builds with pkgsMusl
        • stack builds with its own Stackage snapshot via stack2nix
        • The stack 1.9 official release uses this toolchain for its static build
      • intray-web-server (which includes, amongst others, servant) (CC @NorfairKing)
        • got that to work in this non-master commit
      • dhall (CC @Gabriel439)
      • cachix (CC @domenkozar)
      • xmonad
        • compiles with this hack but doesn't seem run, at least not on Ubuntu 16.04, due to libgmp.so.3 error
        • libgmp error is gone since Fully static Haskell executables - overview issue #43795 (comment)
      • pandoc (CC @jgm)
        • working but this hslua test case segfault might mean some functionality will crash
          • a workaround appears available by increasing musl's small-by-default stack size
      • darcs
        • This one was a bit tougher because it requires system dependencies like libcurl which itself has many dependencies, and had to fix a cabal issue for it, but it's working now.
      • aura
  • static-haskell-nix CI build that tracks nixpkgs master to find breakage early (done)
  • Hydra CI builds all Haskell executables in nixpkgs statically
    • Ensure that Hydra doesn't build (and thus redistribute) static binaries that are weaker than LGPL from dependencies that are LGPL or stronger; see here for the plan
  • crossSystem = { config = "x86_64-unknown-linux-musl"; }; support is working (done by @dtzWill)
  • pkgsMusl support has landed in nixpkgs master (done by @dtzWill)
  • A fix for the duplication of linker flags issue is available in master
    • For Haskell packages with many dependencies, this issue creates Argument list too long when linking
    • A workaround (by @angerman) is available (cherry-pickable from here) but it will require a GHC rebuild and is unlikely to get merged
  • The Cabal --enable-executable-static feature is available in nixpkgs
    • This makes it possible to enable static building without having to change the cabal file; so we can pass this for a view into haskellPackages where all exes are statically linked
    • a Cabal release is available that includes it
      • the upstream PR has been merged
  • The Cabal --ld-option GHC passthrough feature is available in nixpkgs
    • This makes it possible to pass static-linking related linker options (such as linking in .a files) only at the linker stage
    • a Cabal release is available that includes it
      • the upstream PR has been merged
  • All key non-Haskell dependencies provide static libraries (.a files)
    • ncurses
      • The ncurses .a and tinfo fix has been merged to staging (done by (@shlevy)
      • The ncurses .a and tinfo fix has been merged to master (this is a mass-rebuild PR) (merged)
      • This patch (part of this PR by @dtzWill) can be used as a cherry-pickable workaround until the fix in staging has landed in master (only .a fix, not tinfo part, because it's not a mass-rebuild PR
  • pkgsStatic - a fully static overlay
    • Wait for Adding pkgsStatic: a fully static overlay #48803 to add pkgsStatic to nixpkgs master (@matthewbauer)
    • Move static-haskell-nix on top of it (move system dependency overrides that add static libs there)
      • Since Fully static Haskell executables - overview issue #43795 (comment) pkgsStatic can be used as a base.
    • Make nixpkgs overlay to include archive files that's not pkgsStatic (Provide middle-ground overlay between pkgsMusl and pkgsStatic #61575), then drop commit pkgsStatic: Don't disable .so files. from forked nixpkgs
    • Merge all of @nh2's nixpkgs fork's commits to nixpkgs master
      • git: Don't depend curl-config when cross-compiling. #61552
      • Issue 61250 coreutils disable test on musl #61471
      • pkgsStatic: Don't disable static on curl for git #66416
      • pkgsStatic: Add libffi override #66417
      • zlib: Add comments regarding static/shared linking #66486
      • zlib: Properly clean up static/shared distinction #66490
      • fetchurl: Make it overridable using callPackage #66503
      • fetchurl: Don't force-override curl's gssSupport to on unnecessarily #66506
      • treewide: Remove unnecessary --disable-static #66759
    • Move static-haskell-nix's Haskell functionality over as well
  • Investigate whether GCC's -ffunction-sections can make final executables even smaller (results)
  • Set up for the project. #129305
    • Buy a dedicated CI server from it (done).
  • Licensing topics
    • Add functionality that allows filtering out (L)GPL packages in static linking
    • Add functionality that allows building with integer-simple instead of integer-gmp, as libgmp is the biggest LGPL dependency of all Haskell programs (see here)
    • Wait for integer-openssl to be ready for use (CC @ch1bo)
      • Add a flag to use it easily

Why is static linking desirable?

Static linking means your executable depends on as few things running on the target system as possible.

For Linux, it means that an executable you build will work on any Linux distribution, with essentially infinite forwards-compatibility (because Linux in general does not change its system call interface).

Statically linked executables do not depend on the target system's libc.

Statically linked executable are incredibly easy to deploy (many Go executables are statically linked, which gave them the reputation of being easy to deploy in the devops world).

Statically linked executables can start faster than dynamically linked ones where dynamic linking has to be performed at startup (of course the startup time depends on the number of libraries to link and the amount of symbols contained within).

Statically linked executables are smaller (up to 4x in our mesurements), mostly because GHC's -split-sections has way more effects with them (for unknown reason for now).

Who is working on or contributing to this

Feel free to add yourself!

• @nh2
• @dtzWill
• @Ericson2314
• @matthewbauer
• @angerman
• @cleverca22

[nh2]

Related:

• Question on how to build static Haskell binaries in nixpkgs How to build statically linked Haskell binaries? #6855
• stack support to make static linking easy Adding --static flag for building static executables with stack? commercialhaskell/stack#3420
• Cabal ignoring ld-options ld-options is not taken into account when passed by command line or cabal.project.local haskell/cabal#4925
• The desire for statically linked bindists of cabal-install itself Provide statically-linked cabal-install releases haskell/cabal#4941

[nh2]

CC @fosskers from here

[nh2]

CC @vaibhavsagar whose blog post got me into working on this

[puffnfresh]

I know NixOS is careful about licenses and distribution. I'm thinking about libgmp, which is LGPL:

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic

(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

(2) If you dynamically link against an LGPL'd library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPL'd library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Can we ensure either one of these if we enable caching of static Haskell executables?

[Gabriella439]

@puffnfresh: Or you could use a version of GHC with simple-integer to avoid the GMP dependency

[puffnfresh]

@Gabriel439 yeah, is that what we'll do for redistributing static Haskell executables?

[vaibhavsagar]

This is great, thanks so much for working on this and creating this issue @nh2!

[dezgeg]

Before doing more of this #43524 -style fixing of individual package builds, could someone give a try of https://github.com/endrazine/wcc (which has been packaged in #43014) in converting shared objects to static objects?

[nh2]

@puffnfresh Every Haskell package already has a license field (upstream and it's available as a field in nixpkgs).

The best solution seems to be to traverse the licenses of all things linked and ensure that Hydra does not build statically linked exes where one of the dependencies is LGPL or stronger (unless the final project itself is also LGPL or stronger anyway).

For executables blocked that way, a fallback should happen where it's checked if the issue goes away if integer-simple was used instead; then Hydra can build it that way.

[nh2]

Before doing more of this #43524 -style fixing of individual package builds, could someone give a try of https://github.com/endrazine/wcc (which has been packaged in #43014) in converting shared objects to static objects?

@dezgeg It sounds interesting and may be worth a try but there may be the independent questions whether I want "binary black magic" (as wcc calls it) in my production binaries.

Nix is already pretty custom in its build process, I wouldn't want an upstream library author reject my bug report about a segfault with "well you use totally custom tools, if you just used our normally built static libs we would be more eager to look into that". It's a good feature if nix's builds still essentially are a series of "normal" build steps (compiler and linker invocations).

I haven't looked into wcc in detail so I cannot judge its safety, but my intuition tells me I'd rather sponsor Hydra some build servers and HDs than turn dynamic libs into static ones and have the risk of unexpected behaviour.

[jgm]

We already provide fully static builds of pandoc with each release, using docker and alpine.
The build process can be found in the linux/ directory in pandoc's repository.