| 31 Oct 2025 |
 Gaétan Lepage | Oh, I was implying "all caps enabled" | 21:39:18 |
 apyh | lemme try it :3 | 21:43:58 |
 connor (burnt/out) (UTC-8) | stdenv can be cudaPackages.backendStdenv if the version of GCC is supported by NVCC. It’s only different when we need to use an older version of GCC.
NVCC shouldn’t leak the GCC wrapper since it should be largely build-time only. Any ideas why it’s propagating like that? | 21:46:06 |
| Gaétan Lepage | Thanks for the follow-up.
The leakage chain is:
cudaPackages.cuda_nvcc -> cudaPackages.nccl -> firefox-unwrapped -> firefox.
In cuda_nvcc.nix, backendStdenv.cc is added into cuda_nvcc's propagatedBuildInputs. | 21:50:01 |
| Gaétan Lepage | https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/cuda-modules/packages/cuda_nvcc.nix#L24-L25 | 21:50:06 |
| apyh | do you have a command / nixpkgs config for me to work with or nah? | 21:50:14 |
| apyh | just wanna bench against yours :p | 21:50:22 |
| 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:13:01 |
| Gaétan Lepage | So, either:
A) we get rid of propagatedBuildInputs = [ backendStdenv.cc ] in cuda_nvcc's derivation. But I suspect that it is there for a (good) reason.
B) We relax firefox's disallowedRequisites to disallowedReferences. | 22:15:26 |
| 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 |
