| 15 Nov 2024 |
 p14 | Oh right, that could be a problem if someone uses nixpkgs on a on-nixos system. :( | 11:59:00 |
 emily | well, but, we do pass all sorts of -isystem and -sysroot stuff | 12:00:11 |
| emily | so I dunno if it comes up or not | 12:00:19 |
| p14 | Still could be a problem if extra stuff is in the include search path | 12:00:31 |
| emily | extra stuff like? | 12:00:48 |
| emily | not denying it could be a problem, just want to understand the scenario better | 12:00:56 |
| p14 | At least it could manifest as the underspecified dependency problem: user thinks it's working, but it's only working by accident because they have stuff in /usr/include. | 12:01:04 |
| p14 | And then separately I don't know if we can assume those things defer to the wrapper's -i-flags in precedence or not. | 12:02:01 |
| emily | honestly the real solution is a proper sysroot or something (but there were issues with that too last time it was talked about in here) | 12:02:53 |
| p14 | How do you define "proper sysroot" and how does it help if the compiler can look somewhere you don't want it to look? | 12:03:18 |
| emily | really though there's so many ways for impurities to leak in outside of the sandbox | 12:03:20 |
| p14 | fair. | 12:03:29 |
| emily | In reply to @p14:matrix.org
How do you define "proper sysroot" and how does it help if the compiler can look somewhere you don't want it to look? it's not going to look outside of the sysroot if we provide one | 12:03:36 |
| emily | but there were complications with it needing to be / for something something something | 12:03:47 |
| emily | I forget, it was a few weeks ago | 12:03:51 |
| emily | if you mean -I/usr/include, uhh | 12:03:57 |
| emily | well (a) that's your fault for passing that and (b) we have a joke of a cc command-line parser in the wrappers to try and filter those out | 12:04:14 |
| emily | which ALSO broke Darwin and I had to change it | 12:04:21 |
| emily | (because on Darwin it's relative to the SDKROOT, so e.g. -L/usr/lib/swift is benign) | 12:04:38 |
| p14 | I was under the impression the compiler driver searched usr lib of its own volition | 12:04:41 |
| emily | it searches <sysroot>/lib | 12:04:53 |
| p14 | https://github.com/llvm/llvm-project/blob/d7b669b3a30345cfcdb2fde2af6f48aa4b94845d/clang/lib/Driver/ToolChains/Gnu.cpp#L2930
Oh, right. | 12:05:11 |
| p14 | And, we're not passing sysroot then I take it. | 12:05:22 |
| emily | like I said apparently it has to be / but I forget why | 12:05:36 |
| emily | (on Linux) | 12:05:39 |
| p14 | that sounds odd, what's the point in having a sysroot parameter if that was true? | 12:05:53 |
| emily | it was an arcane reason. ask trofi :) | 12:06:07 |
| 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 |
