Given a derivation that builds a binary for nix, is there a way to tweak that derivation so that the result is a standard FHS compatible Linux binary, ready to be downloaded and run on most Linux systems without the need for nix? Or is nix only capable of building binaries integrated with dependencies in the nix store? If there is a way, how would this be done?
2 Likes
Have not tested it myself but take a look at nix bundle. From man page:
packs the closure of the installable into a single self-extracting executable
https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-bundle.html
The reason I’m asking is: I’m working on the package for godot, the game engine. Building godot from source entails running scons with various flags. One set of flags builds the tools. Another builds what’s called an “export template”, which is itself a binary of some kind. When you’ve made a game in the godot tool, you can export your game for a target platform by selecting an export template built for that platform. Thus, there needs to be an export template for 32/64 bit Linux, windows, Android, ios, etc. These can each be built by passing different flags to scons when building the export template.
Thing is, if I build the export template from nixpkgs, the result is essentially a template that lets you export a game to work on nixos, not standard Linux environments. I was hoping there’s a way to have a derivation that builds a standard Linux template (and one for each other platform).
Thus, I don’t think nix bundle addresses this problem. Thanks for the suggestion though!
Building binaries for non-nix environments with nixpkgs build support infrastructure is not easy. nixpkgs just isn’t designed for that. You can still do it with nix, but you’ll probably have to throw stdenv out the window and work at a really low level. Also look into unwrapped versions of compilers.
I see… Okay, thanks!
To that end, I have this… silly thing, which may be helpful: Comparing NixOS:master...ElvishJerricco:run-in-fhs · NixOS/nixpkgs · GitHub
Basically, it takes a derivation and builds it in an FHS user env instead (i.e. you only need it if that derivation wouldn’t have successfully built normally). You still likely have to throw out… most of nixpkgs. But in theory you could build up a package ecosystem where all of them run in an FHS env like this and all of them rely on FHS stuff.
3 Likes
I found an example overlay to bring old glibc into recent nixpkgs here: stdenv's linuxHeaders (or allowedRequisites) incorrect in the presence of overlays overriding glibc · Issue #174236 · NixOS/nixpkgs · GitHub
With that overlay I was able to build something from nixpkgs master that could run with the Ubuntu 18.04 dynamic linker (after patchelf-ing in the interpreter and replacing/removing RPATH entries).
nixpkgs has a bunch of stdenvs already (gcc<N>Stdenv), but only a single glibc. It would be really cool if we had an easier/more reliable way to supply custom glibc, to allow runtime linking with old Linux FHS distros.
Related, Guix seems to have a make-gcc-toolchain for this purpose: https://stackoverflow.com/questions/66063337/build-against-an-old-glibc-with-guix
1 Like