| 27 Oct 2024 |
 emily | and on Linux of course it only applies to dev shells since there's the sandbox, so it's not quite as critical. | 21:45:53 |
| emily | (and on Darwin the purity hacks are causing us more problems than they solve, so I'd personally be happy to gamble with a cleaner approach that seems like it ought to work.) | 21:46:11 |
 trofi | 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. | 21:55:38 |
| trofi | -isysroot might not be as devastating, but AFAIU it only affect include search prefix while you probably want library search change as well. | 21:58:07 |
 Artturin |
This option is like the --sysroot option, but applies only to header files (except for Darwin targets, where it applies to both header files and libraries). See the --sysroot option for more information.
| 21:58:55 |
| Artturin | * isysroot
This option is like the --sysroot option, but applies only to header files (except for Darwin targets, where it applies to both header files and libraries). See the --sysroot option for more information.
| 21:59:04 |
| trofi | TIL | 22:00:03 |
| trofi | I wonder how transitive library dependencies are handled there. | 22:00:29 |
| emily | I didn't know Darwin handled it differently but that makes sense… | 22:00:54 |
| emily | in a messed up kind of way | 22:00:59 |
| 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. what kind of changes do you think we might need to make something like this work for us? we could patch in a semantics change, but that's kinda gross. | 22:01:58 |
| trofi | I don't know :) | 22:03:18 |
| emily | fair enough :) | 22:04:25 |
| emily | I would really like to work with the compilers' mechanisms rather than saying "hey, stuff is in /" and post-facto filtering out everything in / | 22:04:52 |
| trofi | Yeah. Unfortunately compilers (and linkers) assume quite a bit about FHS layout: ld.so location, crt?.o file lookup, executable tools (as) lookup, etc. I'd say adding the proper knobs to upstreams (like an arbitrary --prefix= for these things instead of hardcoded paths with various inference rules) might be the best long-term option. But they have to be designed carefully to be compatible (or at least non-conflictings) with --sysroot= stuff, cross-compiling directory switch, multilib switch, etc. | 22:10:21 |
| emily | right. | 22:11:11 |
| emily | in Darwin we have the situation where we have switched to assembling a "normal"-structured sysroot for the basic system library set – which in our case is not FHS but instead the Xcode SDK layout – because it is much more compatible with build systems (and anyway contains only headers and stub libraries) | 22:12:13 |
| emily | which meant having to patch the purity filter to be aware of the fact that things like -L/usr/lib/swift are relative to that sysroot and therefore shouldn't be filtered | 22:12:36 |
| emily | I'd love to do more working with upstreams to get the appropriate knobs for our toolchains. I would be happiest if we didn't have wrappers at all | 22:13:04 |
| emily | but the state where we have a half-broken command-line parser just to filter out build systems that pass in -I/usr/whatever in non-build development shells on non-NixOS … is sad to me | 22:13:39 |
| trofi | yeah, wrappers are a disaster | 22:13:42 |
| emily | the juice may be barely worth the squeeze, but I just spent several days fighting the squeeze on Darwin and it's been a pain | 22:14:12 |
| emily | and there's so many ways you can bypass it inadvertently to get a bad path into the argv anyway. | 22:14:26 |
| emily | so, one thing about the sysroot is that apparently at least on Darwin -isysroots stack, so we could do a thing where we pass one that just contains empty ./usr/lib etc., and overlay our SDK sysroot on top of that. I don't know if it's possible to do that with Linux toolchains, though. | 22:15:28 |
| emily | but if it is, we could maybe have such a stub sysroot to catch common errant -I and -L paths, and then "overlay" / on top to get DT_NEEDED etc. working? | 22:15:57 |
| emily | it's possible that all this is just weird Darwin-specific behaviour that we can't replicate on Linux though. | 22:16:10 |
| trofi | I had an impression that to get a sysroot prefix addition on linux you need to add = in front, like -L=/usr/lib. Otherwise it will use unprefixed path. Linker scripts have an exception though that if the linker script is within the sysroot the prefix is added anyways even if = is not prepended: https://sourceware.org/binutils/docs/ld/File-Commands.html | 22:21:34 |
 Randy Eckenrode |
In case a sysroot prefix is configured, and the filename starts with the ‘/’ character, and the script being processed was located inside the sysroot prefix, the filename will be looked for in the sysroot prefix. The sysroot prefix can also be forced by specifying = as the first character in the filename path, or prefixing the filename path with $SYSROOT.
| 22:23:06 |
| Randy Eckenrode | That hurts my brain to parse. | 22:23:42 |
| trofi | If a linker script is in sysroot directory and /foo paths will work like =/foo paths :) | 22:24:09 |
