Statically link executables for haskell packages by default

[domenkozar]

Since the merge of multiple outputs PRs (#27196 and #27209) we have a separate bin output.

Meanwhile we have more and more packages in all-packages.nix that build with justStaticExecutables.

Since we also have dead code elimination for darwin and linux, could we now default to static executables so that runtime closure is really minimal?

[peti]

If it comes to optimizing the size of the run-time closure, then I'd rather see ghc's base libraries put into a separate output so that dynamically linked executables no longer need the entire compiler. Technically speaking, static linking does not reduce the closure size -- it increases it.

[domenkozar]

@peti technically - yes. But in practice, just downloading 300 files is an overhead. With static linking you can optimize dead code elimination pretty far, going above the bar of dynamic linking that has to include all symbols.

The executables in Haskell end up being quite small - around 10MB up to 30MB.

I could prepare some numbers to compare.

[peti]

Downloading 300 files is an overhead.

That depends ... if you're installing not just one Haskell executable but several, then a significant part of those 300 store paths might get re-used. Also, Haskell library store paths tend to be small, so downloading 300 of them is no big deal, actually. Last but not least, I'm not entirely sure that the number "300" is actually an accurate guess. :-)

With static linking you can optimize dead code elimination pretty far, going above the bar of dynamic linking that has to include all symbols.

Yes, that is true. The optimizer can do more in statically linked builds. Also, there is the issue of startup-times, i.e. statically linked Haskell binaries like git-annex etc. tend to start much faster than dynamically linked ones.

[domenkozar]

My argument about 300 dependencies comes from experience that you quickly depend on lens, etc and without any effort you have 100 deps. Then those just double doing anything web related.

Usually one wouldn't have more than a couple haskell executables on server - in most common sense.

Stack for example does the same: dynamic linking for libraries (to support TH) and static for executables (so they are relocatable on their own).

Another reason to try this is to fix packages closure like #29011

[peti]

It would be really nice to have those intuitions backed up by some actual numbers.

[domenkozar]

@peti agreed, i'll collect some data to back these claims and see closure differences when using statically compiled executables

[peti]

I guess I'd be in favor of making this change if we disable shared library builds at the same time, i.e. let's not build dynamic libraries at all if we're not going to use them for our own executables. Developer tools like stack and cabal-install don't use them by default either, so I suppose we can just drop them from the default configuration entirely.

[peti]

I have pushed 0c347f8f0b75a3ce48bfceee1ad32264a027f58a for test building at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates. This change will arrive on master in the next couple of days.

[peti]

Interestingly enough, GHC can no longer build the unit tests after shared library builds are disabled! Any attempt to compile a test suite fails, i.e. https://nix-cache.s3.amazonaws.com/log/52770n36s1b33bq3ywlml65adhh57nfw-QuickCheck-2.10.1.drv. 😕

[matthewbauer]

This seems like a weird thing to do given that we pass --disable-static everywhere else.