| 15 Nov 2024 |
 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:matrix.org | 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:matrix.org | 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:matrix.org | 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 |
| emily | right, we can't do env -- because we want it to be a binary path rather than an argv | 15:12:53 |
| emily | though some of the other things in there will already break if you give them options so maybe we should be doing wrappers of some kind anyway | 15:13:10 |
| emily | the advantage of our own tiny C program is that it inherently doesn't depend on fetching. | 15:14:08 |
| sterni | It's a bit silly that we can't really return the empty string. | 23:55:21 |
| 19 Nov 2024 |
| emily | yeah. well, it makes sense that we want something that's usable as an argv[0] | 00:08:01 |
| emily | I lean towards just vendoring the C program, but if that doesn't fly I feel like my PR is an improvement. | 00:08:29 |
