that adds “pkgsStatic” which can be used to build statically linked packages from the original package set. This is very similar with how pkgsMusl works, but pkgsStatic also adds a “cross” overlay that modifies things to always build statically when possible. Unlike with most overlays, though, crossOverlays will only override the packages you are building, not your build tools. It is able to use a lot of the cross infrastructure to accomplish this.
What are the opinions on this? Are static packages something that we want to build? Or does this increase the scope too much.
Will this make it possible to build “self contained” binaries that is not hardlinked to the /nix/store path? In that case, it would make nix an amazing tool for building packages for the HPC cluster we use.
I’m very excited about developments in this area as well! I suspect many users have a use case where they can freely use nix on the build / CI servers, but don’t have it installed with running daemons on the production servers; being able to build and deploy statically linked binaries without references to the nix store is a great boon for that environment.
I know you’ve also worked on tools like nix-bundle, which look very compelling for this use case as well, but there’s something to be said for having a vanilla ELF binary that “just works” and is relatively simple (not to mention no need for user namespace support).