| 31 Oct 2025 |
 Gaétan Lepage | * Actually, the leakage is not transitive.
Firefox uses disallowedRequisites, not disallowedReferences.
The former makes the specified references illegal in all (transitive) dependencies. Conversely, disallowedReferences only forbids them in the result of the current derivation.
Basically, I can build cudaPackages.nccl with disallowedReferences = [ backendStdenv.cc] bot not disallowedRequisites = [ backendStdenv.cc ].
So, if I understand correctly, having propagatedBuildInputs = [ backendStdenv.cc ] in cuda_nvcc's derivation is fundamentally incompatible with having disallowedRequisites in firefox's wrapper derivation. | 22:17:36 |
| Gaétan Lepage | Actually, I was able to build python3Packages.torch and firefox with an empty propagatedBuildInputs in cuda_nvcc. Why do we need it exactly? | 23:25:46 |
 connor (burnt/out) (UTC-8) | If it’s in propagatedBuildInputs it should still slide out of the dependencies far enough down
It likely worked because the current stdenv is supported by the version of NVCC in the default CUDA package set
stdenv.cc needs to be in NVCC’s propagatedBuildInputs because NVCC needs it available it when it is in nativeBuildInputs | 23:28:42 |
| connor (burnt/out) (UTC-8) | I believe Firefox-unwrapped and Firefox should use disallowedReferences. I’m trying to think why it’s okay to try to block that transitively? | 23:30:54 |
| Gaétan Lepage | Thanks! Opened https://github.com/NixOS/nixpkgs/pull/457391. Let's see what the firefox maintainers think. | 23:42:18 |
| 1 Nov 2025 |
 SomeoneSerge (back on matrix) | Catching up just now, but I do not see any conclusion on why and how firefox retains a path to gcc after the build? | 01:50:57 |
| SomeoneSerge (back on matrix) | That should not be happening | 01:51:02 |
| SomeoneSerge (back on matrix) | Ah. We didn't used to have that, cc in propagated inputs Since when do we? We did used to propagate a hook though, I forget under what conditions if any | 01:53:05 |
| SomeoneSerge (back on matrix) | commit c03326445b067dca37ea323d998ffa3d520adb6d
Author: Eelco Dolstra <edolstra@gmail.com>
Date: Tue Sep 26 22:37:38 2017 +0200
firefox: Remove about:buildconfig
Storing the build configuration caused Firefox to retain a dependency
on gcc, glibc.dev and icu4c.dev.
This reduces the size of the firefox closure from 587 to 415 MiB.
Wow that's old now
| 02:01:52 |
 hexa (UTC+1) | And we still remove that, because it pulls in all kinds of shit and bloats the closure | 02:02:13 |
| hexa (UTC+1) | I think you should have a very good reason to propagate a build time dependency | 02:03:41 |
| connor (burnt/out) (UTC-8) | We propagate CC so that NVCC can use it:
- https://github.com/NixOS/nixpkgs/blob/a4c85a90eb7864e01fe46ffc6dbeb23a970c8fc3/pkgs/development/cuda-modules/packages/cuda_nvcc.nix#L24-L25
- https://github.com/NixOS/nixpkgs/blob/a4c85a90eb7864e01fe46ffc6dbeb23a970c8fc3/pkgs/development/cuda-modules/packages/cuda_nvcc.nix#L150-L151
And we have a setup hook which sets relevant environment variables for CMake and enables discovery of CUDA packages:
- https://github.com/NixOS/nixpkgs/blob/a4c85a90eb7864e01fe46ffc6dbeb23a970c8fc3/pkgs/development/cuda-modules/buildRedist/default.nix#L282
- https://github.com/NixOS/nixpkgs/blob/a4c85a90eb7864e01fe46ffc6dbeb23a970c8fc3/pkgs/development/cuda-modules/packages/setupCudaHook/setup-cuda-hook.sh#L82-L95
| 02:09:46 |
| hexa (UTC+1) | shouldn't that be propagatedNativeBuildInputs? | 02:10:31 |
| connor (burnt/out) (UTC-8) | For backendStdenv.cc in cuda_nvcc.nix or for setupCudaHook in buildRedist/default.nix? | 02:11:19 |
| hexa (UTC+1) | cuda_nvcc.nix | 02:12:14 |
| SomeoneSerge (back on matrix) | Here's the old logic: https://github.com/NixOS/nixpkgs/blob/99fe7bea35ed3ca8de66188d2337cb3e7c6e83e7/pkgs/development/cuda-modules/_cuda/fixups/cuda_nvcc.nix#L50 | 02:12:30 |
| hexa (UTC+1) | it's too late here, going to sleep | 02:13:19 |
| connor (burnt/out) (UTC-8) | backendStdenv.cc needs to be in propagatedBuildInputs; makeSetupHook does the same thing | 02:13:21 |
| SomeoneSerge (back on matrix) | We do reference the host compiler from nvcc and from the hook, but we do not propagate | 02:13:46 |
| SomeoneSerge (back on matrix) | Tbh the hook referencing the compiler looks sus too, but my memory's all gone | 02:16:08 |
| SomeoneSerge (back on matrix) | Ah! I see now why the hook was "ok": it would only propagate stuff if cudaPropagateToOutput is explicitly set by the downstream derivation | 02:21:42 |
| SomeoneSerge (back on matrix) | Ok but the onnxruntime part I didn't look at/don't know don't understand | 02:23:57 |
| SomeoneSerge (back on matrix) | My best guess is it's because an extraneous propagatedBuildInputs = [ setupCudaHook ] also slipped in into buildRedist.nix, but tbh I'm still struggling to explain how this leads to the extra reference | 02:51:56 |
| SomeoneSerge (back on matrix) | Another person on gh saying they found a legit nvcc reference in libonnxruntime_providers_cuda, so I think this can't be explained by hooks alone | 02:56:09 |
| connor (burnt/out) (UTC-8) | Is it possible onnxruntime does JIT compilation | 02:57:40 |
| SomeoneSerge (back on matrix) | Yeah that what I'm wondering | 03:10:52 |
| SomeoneSerge (back on matrix) | Nope | 03:12:13 |
| SomeoneSerge (back on matrix) | More mysteries! https://github.com/NixOS/nixpkgs/pull/457424#issuecomment-3475537174 | 03:15:11 |
| SomeoneSerge (back on matrix) | connor (burnt/out) (UTC-7): when you started propagating crt/host_config.h from cudart, did you also drop the manual nvcc from any leaf packages? Figure you might be quicker to answer than me reading or running tests | 03:58:51 |
| connor (burnt/out) (UTC-8) | Manual NVCC? | 04:00:59 |
