summary refs log tree commit diff
path: root/pkgs/os-specific/linux/systemd/default.nix
diff options
context:
space:
mode:
authorsternenseemann <sternenseemann@systemli.org>2023-01-03 22:19:59 +0100
committersternenseemann <sternenseemann@systemli.org>2023-01-03 22:19:59 +0100
commit1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b (patch)
treea052a95d9708a38797ddb420f3b8f20b8168c443 /pkgs/os-specific/linux/systemd/default.nix
parent3665c429d349fbda46b0651e554cca8434452748 (diff)
downloadnixpkgs-1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b.tar
nixpkgs-1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b.tar.gz
nixpkgs-1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b.tar.bz2
nixpkgs-1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b.tar.lz
nixpkgs-1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b.tar.xz
nixpkgs-1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b.tar.zst
nixpkgs-1ee0f4c2aa2f6f70dca68c0d9bc51663a923bf2b.zip
systemd: fix evaluation in pkgsCross.ghcjs.buildPackages
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]: https://github.com/NixOS/nixpkgs/commit/c739c420db5b9d56c335414be1696c57f2dbbb6a#diff-3209527bd27cbc775f579b1e295b0264c850859c7245d526965cec456b8c70a4R61
Diffstat (limited to 'pkgs/os-specific/linux/systemd/default.nix')
-rw-r--r--pkgs/os-specific/linux/systemd/default.nix15
1 files changed, 11 insertions, 4 deletions
diff --git a/pkgs/os-specific/linux/systemd/default.nix b/pkgs/os-specific/linux/systemd/default.nix
index 91746b9f109..4e3f3762370 100644
--- a/pkgs/os-specific/linux/systemd/default.nix
+++ b/pkgs/os-specific/linux/systemd/default.nix
@@ -70,9 +70,16 @@
 
   # the (optional) BPF feature requires bpftool, libbpf, clang and llvm-strip to be available during build time.
   # Only libbpf should be a runtime dependency.
+  # Note: llvmPackages is explicitly taken from buildPackages instead of relying
+  # on splicing. Splicing will evaluate the adjacent (pkgsHostTarget) llvmPackages
+  # which is sometimes problematic: llvmPackages.clang looks at targetPackages.stdenv.cc
+  # which, in the unfortunate case of pkgsCross.ghcjs, `throw`s. If we explicitly
+  # take buildPackages.llvmPackages, this is no problem because
+  # `buildPackages.targetPackages.stdenv.cc == stdenv.cc` relative to us. Working
+  # around this is important, because systemd is in the dependency closure of
+  # GHC via emscripten and jdk.
 , bpftools
 , libbpf
-, llvmPackages
 
 , withAnalyze ? true
 , withApparmor ? true
@@ -86,7 +93,7 @@
 , withHostnamed ? true
 , withHwdb ? true
 , withImportd ? !stdenv.hostPlatform.isMusl
-, withLibBPF ? lib.versionAtLeast llvmPackages.clang.version "10.0"
+, withLibBPF ? lib.versionAtLeast buildPackages.llvmPackages.clang.version "10.0"
 , withLocaled ? true
 , withLogind ? true
 , withMachined ? true
@@ -368,8 +375,8 @@ stdenv.mkDerivation {
     ]
     ++ lib.optionals withLibBPF [
       bpftools
-      llvmPackages.clang
-      llvmPackages.libllvm
+      buildPackages.llvmPackages.clang
+      buildPackages.llvmPackages.libllvm
     ]
   ;