| 15 Nov 2024 |
 emily | In reply to @trofi:matrix.org
At least on linux the attempt to use non-standard sysroot broke DT_RUNPATH lookups for libraries not explicitly mentioned in the linking process: https://github.com/NixOS/nixpkgs/pull/213185. Transitive libraries are searched in sysroot only and things break. p14: here's a pointer to the previous discussion | 12:10:44 |
| emily | with the conclusion of basically "we should add more knobs upstream and then twiddle only the ones we need" | 12:11:08 |
| emily | which would give us a path to dropping -nostdlibinc without regressing things | 12:11:16 |
 p14 | This can of worms is too big to eat. I'm going to leave nostdlibinc in, and send the PR to push it into the wrapper at least. | 12:13:42 |
| p14 | https://github.com/NixOS/nixpkgs/pull/356162 | 12:22:14 |
| p14 | In reply to @p14:matrix.org
I've come up with a possible use case for this abandoned PR https://github.com/NixOS/nixpkgs/pull/355000
Being able to put link-only flags in it for clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument] would be useful. Sensible?
An alternative route would be to bracket these flags in --start-no-unused-arguments and --end-no-unused-arguments.
Any opinions on this one? Introduce cc-cflags-link, and then wire link-specific flags into it? Or ignore unused args in more places? | 12:24:13 |
| 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 |
