| 15 Nov 2024 |
 emily | it's really silly | 09:07:08 |
 p14 | I'm unclear on what should move to the wrapper or how to move it - how do we prevent the compiler from adding doing something internally? | 09:07:39 |
| p14 | * I'm unclear on what should move to the wrapper or how to move it - how do we prevent the compiler from adding paths internally? | 09:07:46 |
| emily | our current patch literally just hacks up the command line parser to forcibly insert -nostdlibinc | 09:07:58 |
| emily | we could just … pass -nostdlibinc in the wrapper (with the Darwin exception) | 09:08:07 |
| emily | that's not A Solution, but it accomplishes the same behaviour as currently for wrapped compilers without rebuilding Clang | 09:08:23 |
| emily | * that's not A Solution, but it accomplishes the same behaviour as currently for wrapped compilers without rebuilding Clang for different targets | 09:08:28 |
| emily | and, yeah, it changes unwrapped compiler behaviour. but it changes it to be more normal and more upstream and I think that's good? | 09:08:48 |
| p14 | Oh. Right. Brain was in the wrong mode. I now comprehend the silliness of the patch. | 09:09:22 |
| p14 | At least ISTM that it can move to the wrapper and I follow your rationale for it. | 09:09:49 |
| emily | yeah so when I investigated this last I think I just misinterpreted that bug you linked as talking about an unwrapped compiler | 09:10:05 |
| emily | seeing how ancient these patches are, I now believe that the reason it's applied to the unwrapped compiler is "shrug" | 09:10:24 |
| p14 | I could believe that. | 09:10:36 |
| emily | I do think we should find a way of solving this libc++ issue that isn't -nostdlibinc, but if we move it to the wrapper the pressure is reduced | 09:11:05 |
| emily | and we get a fully target-independent Clang :) | 09:11:21 |
| p14 | Yeah, and it's easier to develop since it won't require rebuilding clang. | 09:11:24 |
| p14 | (When someone does get around to it) | 09:11:34 |
| emily | well, wrapper changes aren't much kinder 😅 | 09:11:37 |
| emily | though you can at least override the wrappers for specific derivations | 09:11:43 |
| p14 | Yup | 09:11:48 |
| emily | you Linux people don't know how good you have it – changing LLVM doesn't even restart the entire bootstrap | 09:11:58 |
| p14 | Muahah | 09:12:04 |
| p14 | Yeah, definitely glad I don't have to deal with that. | 09:12:29 |
| emily | instead you have to deal with GCC. | 09:12:50 |
| p14 | Well there is that. | 09:12:56 |
| p14 | I've got a moment to mess with this and send a patch to drop the patch unless you want the fun. Will let you know if I have to give up for some reason. | 09:14:08 |
| p14 | I have a handful of trivial patches outstanding which would be nice to not let languish until I forget about them: https://github.com/NixOS/nixpkgs/pulls/pwaller | 09:15:07 |
| emily | would be happy to review :) | 09:15:44 |
| p14 | The failures mentioned in https://github.com/NixOS/nixpkgs/pull/354471 raise my eyebrows a bit, not sure what's going on there. | 09:15:45 |
| emily | I've been having too much LLVM fun myself already lately: https://github.com/NixOS/nixpkgs/pull/354107 | 09:16:13 |
