| 11 May 2025 |
 Alyssa Ross | Is there a point in closing them? | 15:06:07 |
 Tristan Ross | Well if it's not going to be worked on anytime soon, why leave like a 2yo PR that has merge conflicts open? | 15:07:18 |
 emily | it was closed in 2022? | 15:07:48 |
 @trofi:matrix.org | looking at the comment it broke meson-based builds on clang (and they used to work by accident by using a wrong compiler) | 15:08:53 |
 p14 | But is there a good reason to put the unwrapped CC in the path? I have dropped it without ill effect and it does fix things ion my case. | 17:17:03 |
| emily | we don't but we do want prefixed compilers | 17:18:55 |
| emily | so the prefixed ones should probably be wrapped | 17:19:10 |
| p14 | So, could https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/cc-wrapper/setup-hook.sh#L92-L94 and https://github.com/NixOS/nixpkgs/blob/1a5bd697adecf27385b69352485baa52a6e02fe9/pkgs/build-support/bintools-wrapper/setup-hook.sh#L39-L41 be dropped.
In light of the commit message here https://github.com/NixOS/nixpkgs/pull/182385/commits/e682dd84cff5d2420fcc0a40508557477f6cc9d3 which comments that it was unknown why there were in the path (but the answer is linked above). Now it is found, can we delete it? :) | 18:42:09 |
| p14 | I'm thinking that essentially if there is some binary provided by the compiler and it's not symlinked into the wrapper, that is a bug. | 18:43:42 |
| p14 | While messing with the booting machinery I am hitting an odd thing where somehow a meson is creeping in which has an openmp dependency which creates an infinite cycle. Haven't debugged it yet. (clang -> tblgen -> cmake -> libarchive -> e2fsprogs -> fuse -> meson (from some other stage) -> openmp -> infinite cycle on clang). I guess I need to plug something into my stdenv overrides to prevent this. | 18:54:42 |
