| 15 Nov 2024 |
 p14 | I think I'm just going to try. | 12:24:49 |
 emily | also wait | 12:32:09 |
| emily | do we not pass it to GCC? | 12:32:14 |
| emily | if GCC already has the leaky behaviour I don't think there's any justification for keeping this for Clang. | 12:32:36 |
| p14 | No clue what the gcc situation is. | 12:32:50 |
| p14 | emily: I am thinking it would be good to retain nostdlibinc if it means that nixpkgs compilers in a devshell on non-nixos machines aren't broken. It is a compelling use case of nix and I remember encountering difficult to diagnose breakage along those lines when I first used nix. The sort of thing which would be quite offputting for new users. (Admittedly, ditching impurity entirely is better, and is what I eventually did, but that might not be an option for many users/use cases). | 12:44:47 |
| emily | I think we should see what GCC does. | 12:45:13 |
| p14 | I'm only making this argument weakly though. | 12:45:19 |
| emily | if GCC behaves in a leaky manner, then the vast majority of users are already getting that behaviour, and we can table fixing it until we do the proper upstream work | 12:45:26 |
| 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 |
