We now have the information to properly determine the role the
cc-wrapper dependency has, by taking advantage of `offset`. No longer
use the soon-to-be-deprecated crossConfig environment variable, the
temp hack used before this change.
4 far-reaching changes: Smaller PATH, New vars, different propagation
logic, and different hook logic
Smaller PATH
------------
`buildInputs` no longer go on the PATH at build time, as they cannot be
run when cross compiling and we don't want to special case. Simply make
a `nativeBuildInput` too if one needs them on the PATH. Fixes#21191.
Many new depedendency variables
-------------------------------
See the stdenv chapter of the nixpkgs manual. I pulled out the existing
documentation of dependency specification into a new section, and added
language for these two (and their propagated equivalents) along side
the others'.
More complex propagation logic
------------------------------
Before a propagated*XXX*Input always acted as if it was specified
directly as a *XXX*Input downstream. That's simple enough, but violates
the intended roles of each sort of dep, which has functional and not
just stylistic consequences.
The new algorithm is detailed in the manual, and ensures everything
ends up in the right place. I tried to give both an informal and formal
description, but I suspect in practice it will not make much sense
until one tries cross compiling, after which it will immediately make
sense as the only sane option.
Simplified hook logic
---------------------
Rather than `envHook` and `crossEnvHook`, whose behavior differs
depending on whether we are cross compiling or not, there is now one
hook per sort (or rather non-propagated and propagated pair of sorts)
of dependency. These new hooks have the same meaning regardless of
cross compilation. See the setup hook section of stdenv chapter of the
Nixpkgs manual for more details.
This was motivated originally by my cross work, but that goal requires a
few more commits to other things. Still, it's good to start the cleanup
now / get things out of the way.
- Dispatch off more appropriate conditions---`stdenv.cc.is*` and
`hostPlatform.is*` directly---rather than the OS as a proxy.
- Don't worry about pulling in binutils from normal `stdenv.cc` for
`gccMultiStdenv`.
- Defining a `multiStdenv` that uses whatever compiler is default.
- Define `stdenv_32bit` in terms of `multiStdenv`.
stdenvNoCC should not inject any C++ standard library, just as it
doesn't inject any C standard library. stdenv still does, but only
indirectly through stdenv.cc. Wrapped clangs can be simplified now that
they don't need to worry about clobbering CoreFoundation when replacing
the C++ standard library implementation.
This generally-good cleanup should assist with debugging some C++
failures in #26805.
* $out/bin/qemu-kvm should point to qemu-system-aarch64 on aarch64, libvirt expect it
* makeWrapper codes are separated as some architectures might require additional command flags (https://github.com/NixOS/nixpkgs/issues/31606#issuecomment-349675127)
* x86_64-on-i686 is not a native emulation and not supported by KVM, so it is removed from the list
after #29396 removed `-L path/to/dir/of/libstdc++.so` from ld flags
See https://github.com/NixOS/nixpkgs/pull/29396#issuecomment-352600129
Module::Build build helper works correctly when LD is unset (taking LD from Perl
config to be `cc`). However, we can not unset LD because this goes contrary to
the cross compilation effort, and we can not make it propagate ld-is-cc-hook
because it breaks e.g. the build of `libguestfs`. However, #29396 makes LD=ld
incompatible with just 3 perl packages; they are individually fixed by this
commit.
Signal is a bit like google-chrome, wherein the beta version
is independent from the release builds and uses different data
locations and binary names.
