justStaticExecutables: Forbid references to GHC

[9999years]

Description of changes

This makes justStaticExecutables error if the produced store path contains references to GHC. This is almost always erroneous and due to the generated Paths_* module being imported. This helps prevent justStaticExecutables from producing binaries with closure sizes in the gigabytes.

See: #164630

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[maralorn]

I like this.

A bit sad that this makes justStaticExecutables better than enableSeparateBinOutput. I forgot whether there is a per output option regarding requisites.

We will need to make sure that this doesn’t break any of the Haskell binaries that we ship in nixpkgs so this definitely needs to merge into haskell-updates.

[9999years]

@maralorn Agreed, how do I do that? Just change the merge target?

[sternenseemann]

disallowedRequisites needs to become an argument to haskellPackages.mkDerivation and transparently passed on to stdenv.mkDerivation in there. Otherwise disallowedRequisites will only be set depending on override order, i.e. any overrideCabal-based function applied after justStaticExecutables would revert the change again, as it uses a different fix point from overrideAttrs.

[9999years]

@sternenseemann I'm not sure how to make that work; I can add disallowedRequisites to the generic builder, but then I don't have access to the passthru.compiler attribute. I can add a ghc argument with a default value, but then I can't access that in the override unless it's changed from the default due to NixOS/nix#334

Maybe it could be made to work with some functor magic, but I wouldn't know how to wire it up robustly.

[sternenseemann]

@9999years passthru.compiler is set in that function, so it is available as the ghc argument passed in.

[sternenseemann]

Ah, I get what you mean. In principle you can literally add an disallowGhcReference argument tbh.

[sternenseemann]

Or drv: let old = drv; in overrideCabal { disallowedRequisites = [ old.passthru.compiler ]; } old should also work?

[9999years]

OK, I took a shot at it, let me know what you think.

I also checked that the docs render correctly:

[9999years]

@sternenseemann Still looking for a review on this!

[sternenseemann]

Sorry for the wait!

[9999years]

PTAL

[sternenseemann]

I've realized that we can't backport this anymore since this is technically a breaking change. I've moved the changelog entry to the 24.11 release notes as a result. We could backport a version of this which adds the new arguments to haskellPackages.mkDerivation, but doesn't change the behavior of justStaticExecutables.

I've also noticed that we haven't documented disallowedRequisites and disallowedGhcReference to the mkDerivation documentation in the manual, but maybe that's okay since disallowedRequisites is undocumented for stdenv.mkDerivation as well…

[sternenseemann]

@9999years Evals newer than 1806586 of haskell-updates contain your change. There are already a few regressions I've seen on aarch64-darwin. This is not really surprising as GHC can't properly eliminate dead code on that platform. It may be prudent to ignore disallowGhcReference on that platform.

[9999years]

There are already a few regressions I've seen on aarch64-darwin

Which attributes are impacted?

[sternenseemann]

@9999years They should accumulate here. Note that a lot of builds are still pending so the list will get longer as time goes on.