[Nix-dev] Generating nixos-compatible binaries? And bootstrapped packages.

Nick Sabalausky bus_nixos_list at semitwist.com
Wed Aug 24 17:51:07 CEST 2016


Normally, it tends to work out fine on Linux to build an executable 
binary (linked with gcc), and then run the binary on other distros with 
an equal-or-newer glibc.

I realize these binaries won't work out-of-the-box on nixos (something 
about the non-typical directory structure), and the standard preferred 
nixos way is to just recompile ON nixos.

But when there are difficulties in doing so (ex: closed-source, or a 
long chain of bootstrapping involving years of different versions, etc)...

- ...Is there a way binaries can be built on non-nixos linux so that 
they WILL work out-of-the-box on nixos?

- ...Or a simple way to patch a binary to work?

Extra side question: AIUI, Binaries built on nixos do generally work 
out-of-the-box on OTHER nixos installations, right? (assuming compatible 
versions of glibc) Hence the nix binary cache?

----------------------

Also, kind of related: When a package does depend on an older version of 
itself in order to be built from source, what is the nix way of going 
about that?

Ie: Suppose building package foobar v3.0 depends on foobar v2.0, and 
building foobar 2.0 depends on foobar v1.0.

Would there be separate packages "foobar1, foobar2, and foobar3" with 
foobar3 set to depend on foobar2, etc? But then wouldn't that lead to a 
conflict when trying to build/install foobar v3.0 while foobar v2.0 is 
already installed (since it needed to be installed in order to build v3.0)?

Or would the nix expression for foobar v3.0 not *formally* depend on the 
older packages and just simply *internally* download/build v1, then v2, 
then v3? But then down the road, wouldn't that eventually severely bloat 
build times for the latest versions?


More information about the nix-dev mailing list