| 15 Nov 2024 |
 emily | In reply to @emilazy:matrix.org
(because on Darwin it's relative to the SDKROOT, so e.g. -L/usr/lib/swift is benign) one possible path I've considered is making this behaviour configurable for all platforms. we pass -treat-all-those-user-specified-paths-as-sysroot-relative-even-though-this-isnt-darwin -sysroot /directory/tree/with/empty/stub/include/and/libs/directories in the wrapper | 12:06:18 |
| emily | then we're safe from /usr/lib and don't need the broken purity hack CLI parsing in the wrapper | 12:06:32 |
| emily | might work. dunno. | 12:06:39 |
| emily | anyway, I think passing -nostdlibinc for non-Darwin targets in the wrapper is the conservative option for now, but we should definitely flag up to the relevant people that it no longer appears necessary for libc++ | 12:07:50 |
 p14 | Bah, pkgsStatic.pkgsLLVM.hello-cpp.stdenv.cc/bin/x86_64-unknown-linux-musl-clang doesn't work, because it fails to find ld. -ld-path=x86_64-unknown-linux-musl-ld fixes it. | 12:09:09 |
| p14 | * Bah, pkgsStatic.pkgsLLVM.hello-cpp.stdenv.cc/bin/x86_64-unknown-linux-musl-clang doesn't work, because it fails to find ld. --ld-path=x86_64-unknown-linux-musl-ld fixes it. | 12:09:17 |
| p14 | "Bah", because, I expected it to already look for the triple-prefixed ld... | 12:09:31 |
| emily | pkgsStatic.pkgsLLVM even does something sensible? | 12:09:36 |
| emily | In reply to @p14:matrix.org
"Bah", because, I expected it to already look for the triple-prefixed ld... wanna revive the "prefix all compilers" PRs? 😆 | 12:09:45 |
| 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 |
