| 15 Nov 2024 |
emily | if GCC behaves like Clang with -nostdlibinc then sure, keep it (though I'd like to understand why it does behave that way in that case) | 12:45:43 |
p14 | Except where users might be using clang to get a functioning compiler today? | 12:45:44 |
emily | sure | 12:45:51 |
emily | GCC and Clang behaving arbitrarily different in ways that have nothing to do with differences between GCC and Clang is not good though? | 12:46:01 |
emily | and (if that is the case), I don't think we should introduce -nostdlibinc into GCC where it previously was not | 12:46:17 |
p14 | Sure but I like my ratchet to move in the direction of more things working over time, if possible | 12:46:24 |
p14 | Rugpulls are always unpleasant as a user | 12:46:38 |
emily | -nostdlibinc does not just strictly make things work more. it also makes them work less. | 12:47:00 |
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: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 |