[Nix-dev] influence of cpu/kernel version on builds

[Lluís Batlle i Rossell]

On Wed, Mar 07, 2012 at 09:13:45AM +0100, Mathijs Kwik wrote:
> Then I saw this commit come along [1].
> Indeed the only difference I can think of between these machines are the
> kernel version and the hardware itself.
> 
> As nss doesn't depend on the kernel, its store path ends up the same,
> but during compilation, different choices are made.

I'd like to see those build errors. We talked some time ago of patching 'uname'
in stdenv, or something like that.

> Probably other differences can occur as well. Let's assume some package
> checks for availability of SSE4 instructions on the cpu at compile-time
> to decide optimizations to use. Then we end up with a store path which
> isn't portable, but no way to detect this. 

glibc since some version has some hooks that check the cpu at runtime, to check
if it can use strcmp() with sse4 instructions or not for example. But the
store path of glibc will not be different - it's a runtime decision.

> I also can't think of a package that makes
> compile-time choices for cpu, but at least for the kernel version some
> examples reveal themselves. (like nss, but python as well, try to build
> kdeadmin on a machine running kernel 3.2 which built its own python, it
> will fail to find pykde4 because of choices made by python)

One example of a package tuned for the cpu at build time is 'atlas'.

> Now, of course we can try to fix every package that doesn't understand
> linux3's version numbering yet, but that leaves the problem that
> packages _do_ contain internal differences we cannot detect (by looking
> at the store path) depending on what machine built them.

We have the kernelHeaders. Programs should respect kernelHeaders for the kernel
API, and not talk to the running kernel.

> I think there are 2 solutions:
> - record some kernel version number in the store hash.
>   Of course we don't want the full version number, as that would lead to
>   rebuilding your entire system if you upgrade kernels. There are no
>   real differences between 3.0 and 3.2 (not like 2.4 and 2.6 differed),
>   so I don't know what number to look for.
> - trick builders to think they execute on a specific kernel version,
>   probably the version of kernel headers used for glibc.
>   Maybe by just faking 'uname', or some underlying system call that gets
>   used.
> 
> Maybe it's not that big a problem, but it's clear that purity is affected.
> What do you all think? 

We could identify those... and keep a note in nixpkgs at least. We could have
even hacks per derivation. For example, in the nss expression, put whatever is
needed to make it give equal results in different environments.

There is also the problem of non-chroot builds or even non-nixos builds, where
we have some impurities. I think nixpkgs would be much less usable in non-nixos,
if there weren't prebuilt packages. But it takes a non-nixos volunteer to
participate fixing those, and may involve annoying work like patching configure
scripts.

Regards,
Lluís.