[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