| 15 Nov 2024 |
 emily | it makes --sysroot behave improperly. | 12:47:08 |
| emily | (which is the fundamental root of the Darwin issues.) | 12:47:14 |
 p14 | That's a valuable observation | 12:47:22 |
| emily | it happens to guard against impurity because the default sysroot is / | 12:47:38 |
| p14 | Well now it's in the wrapper, can we condition it on --sysroot on the input args? | 12:47:40 |
| emily | but if you use another one, e.g. for cross-compilationā¦ | 12:47:44 |
| emily | I think no because parsing the CLI accurately is impossible, and you need -isysroot too, and etc., and we should be moving in the direction of less parsing in the wrappers rather than more. (and the reason it broke on Darwin is because sometimes --sysroot is an environment variable: SDKROOT) | 12:48:20 |
| p14 | oof. | 12:48:35 |
| emily | but mostly I think we should just figure out what GCC does before even worrying about all this :) if it behaves like Clang's -nostdlibinc then yeah let's just keep it for now | 12:51:10 |
| p14 | In reply to @emilazy:matrix.org
but mostly I think we should just figure out what GCC does before even worrying about all this :) if it behaves like Clang's -nostdlibinc then yeah let's just keep it for now strace -efile -f gcc -c test.c |& grep usr => empty output. Is that enough evidence that it's not scanning inappropriate directories? | 12:52:50 |
| emily | probably :) | 12:53:05 |
| emily | I do really wonder what the difference is. maybe it's just in our 500 GCC patche | 12:53:12 |
| emily | * I do really wonder what the difference is. maybe it's just in our 500 GCC patches | 12:53:13 |
| p14 | :nixos intensifies: | 12:53:32 |
| p14 | https://github.com/NixOS/nixpkgs/pull/356189 | 14:52:14 |
| 17 Nov 2024 |
| emily | do we have something in the wrappers for flags specifically for C, not for C++? | 08:56:53 |
| emily | because a bunch of lines of cc1plus: warning: '-Werror=' argument '-Werror=implicit-int' is not valid for C++ on every C++ compilation seems bad | 09:00:16 |
 trofi | I don't think so. In theory it could be implemented as an else part in https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/cc-wrapper.sh#L143 | 10:59:05 |
| trofi | But generally cc-wrapper is not very precise WRT language-specific options. | 11:00:04 |
| emily | right | 11:01:23 |
| emily | I commented on https://github.com/NixOS/nixpkgs/pull/356545#issuecomment-2481063257 that it may be better to just update to the Git GCC 14. | 11:02:06 |
| emily | since we have to do patch backport work and getting the flags in is awkward. | 11:02:16 |
| emily | the alternative would be to backport even more patches to set the defaults in GCC itself, which would then make pinning gcc13 not work as expected, and also be more work | 11:02:37 |
| trofi | On my system c23 will break at least 80 packages: https://trofi.github.io/posts/326-gcc-15-switched-to-c23.html, about 4% of packages. All of nixpkgs will have quite a few more. | 17:47:50 |
| emily | š« | 17:49:01 |
| emily | 4% didn't seem so bad until I saw the list | 17:49:04 |
| 18 Nov 2024 |
|  @yannis:mozilla.org changed their display name from yannis to yannis|pto_back_nov_26. | 10:40:11 |
 sterni | emily: I don't get why we aren't using env or something instead of execline, surely coreutils or busybox are better optimised w.r.t. closure/bootstrapping? | 15:11:53 |
| emily | IIRC env doesn't work because of CLI arguments or something. https://github.com/NixOS/nixpkgs/pull/324071 originally just used a tiny inline C program but got bikeshedded into using execline because it's there | 15:12:30 |
| emily | I would be okay just doing the tiny inline C program thing | 15:12:35 |
