lsupg Static Builds With GHC 9 (Part 4)

Since I started working on this again at the end of last week, two other people have blogged about the topic! Tom Sydney Kerckhove posted Getting your Haskell executable statically linked with Nix, and Julian Ospald posted Getting your Haskell executable statically linked without Nix. This blog entry addresses why I do not use Nix for lsupg, as well as my current plans for lsupg.

I do not use Nix to build static executables because I found it to be costly in terms of resources and time, especially when trying to support a range of GHC versions. It can be challenging to find revisions of nixpkgs that have working versions of dependencies and cached builds, so that GHC does not need to be built. After finding a working revision, one cannot just use it forever. As discussed in my previous blog entry, it is important to rebuild static executables using new releases of libraries to address security issues. If there is a security vulnerability, I do not want to have to spend a long time trying to find a new valid Nix configuration in order to fix it. If a user needs to build using new packages during a time that I am unable to work on the issue, it may be quite difficult for them to do so themselves, especially if they do not have experience with Nix.

For anybody who is interested in building static executables using Nix, however, here are my current bookmarks on the subject:

• Getting your Haskell executable statically linked with Nix (2024-04-20)
• Cross-compiling and Static-linking with Nix (2021-10-20)
• Building static Haskell binary with Nix on Linux (2020-07-13)
• Building Static Haskell Binaries with Nix (2018-01-03)
• Fully static Haskell executables - overview issue
• nh2/static-haskell-nix

The likelihood of being able to maintain a project is inversely proportional to the cost of maintenance. A project that is difficult to maintain has a good chance of falling behind or being abandoned. A key to minimizing the maintenance cost is to make good use of the work that others are doing. There is a huge amount of work being put into Nix, and the above resources are excellent, but it is still a significant amount of work to maintain updated build configuration. The benz0li/ghc-musl project is very well maintained, but the cost to maintain updated builds is high because of repeated builds of GHC. At this point, I am leaning toward making good use of Julian Ospald’s efforts to provide working Alpine GHC builds with GHCup. I will experiment with this next.