[Nix-dev] Re: [Nix-commits] SVN commit: nix - 18468 - NicolasPierron - nixpkgs/branches/stdenv-updates/pkgs/lib

[Ludovic Courtès]

Hi,

Lluís Batlle <viriketo at gmail.com> writes:

> The kind of information it needs for cross-compilation may be
> *different*, once some of the build system information can be
> automatically asked to the OS or the hardware, but that of the cross
> compilation no.

Right.

> If nix offered a full abstraction of the system where things build or
> things are built for, we would achieve that the information for both
> native and cross builds will be enough and the same.

For pure native builds, I’m pretty sure ‘currentSystem’ and the
dependency graph are all one needs.

For cross builds, this information may indeed be insufficient, because
one can’t actually run code to determine, say, the available CPU or
kernel features.

This would justify an additional ‘host’ argument for expressions that
are to be cross-compiled, possibly with more info than just CPU-kernel.

But then, I find it troublesome if all of Nixpkgs has to pay the price
of this additional complexity, especially now that you showed it’s
possible to natively compile NixOS on the SheevaPlug.

>> glibc, mplayer, etc. all detect this at run time.  (In glibc 2.10, ELF
>> was even extended with ‘STT_IFUNC’ so that code for all ISA variants can
>> be compiled in and the right version is chosen by the dynamic linker.)
> Not all programs may detect that at runtime, and choose that at build
> time. It maybe that it is the case of atlas.

Yes, but then it’s buggy: you wouldn’t be able to rely on an Atlas
binary compiled on the build farm, for instance.  In Nix parlance, this
is actually an impurity.  (GMP’s extended ‘config.guess’ can yield to
similar issues, which is why we override it with the standard
‘config.guess’ [0].)

Thanks,
Ludo’.

[0] http://thread.gmane.org/gmane.linux.distributions.nixos/2227