1ee0f4c2aa
GHC's js backend depends on systemd via emscripten via closure compiler
via jdk via cups. Before it fails to evaluate, though, since
llvmPackages looks into `targetPackages.stdenv.cc` to determine which
C++ library to use (something that should be rectified in the future).
[Unfortunately], for `pkgsCross.ghcjs`, `stdenv.cc` throws which blows
up evaluating `pkgsCross.buildPackages.llvmPackages.clang`.
This is in principle unnecessary. We want to build
`pkgsCross.ghcjs.buildPackages.haskell.compiler.native-bignum.ghcHEAD`
which depends on `pkgsCross.ghcjs.buildPackages.systemd` which needs
clang and friends only in `nativeBuildInputs`, so
`pkgsCross.ghcjs.buildPackages.buildPackages.llvmPackages.clang`.
Unfortunately, due to the nature of splicing, we first evaluate the
“adjacent” derivation before we can access the spliced derivation we are
actually interested in. If the former
fails (`pkgsCross.ghcjs.buildPackages.llvmPackages.clang`), we can't do
the latter.
The solution is to just not rely on splicing in this case and take
`buildPackages.llvmPackages.clang` directly (relative to
`buildPackages.systemd` in this case!) which avoids the whole problem.
[Unfortunately]:
|
||
|---|---|---|
| .. | ||
| applications | ||
| build-support | ||
| common-updater | ||
| data | ||
| desktops | ||
| development | ||
| games | ||
| misc | ||
| os-specific | ||
| pkgs-lib | ||
| servers | ||
| shells | ||
| stdenv | ||
| test | ||
| tools | ||
| top-level | ||