| 15 Nov 2024 |
p14 | Looks like it does, sort of? :) | 12:09:48 |
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 |