| 27 Oct 2024 |
Randy Eckenrode | * I think this is what I wanted.
Add path searchdir to the list of paths that ld will search for archive libraries and ld control scripts. You may use this option any number of times. The directories are searched in the order in which they are specified on the command line. Directories specified on the command line are searched before the default directories. All -L options apply to all -l options, regardless of the order in which the options appear. -L options do not affect how ld searches for a linker script unless -T option is specified.
If searchdir begins with = or $SYSROOT, then this prefix will be replaced by the sysroot prefix, controlled by the ‘--sysroot’ option, or specified when the linker is configured.
| 22:25:34 |
Randy Eckenrode | binutils’s ld interprets -L/usr/lib as /usr/lib always. ld64 does not. What does lld do?
| 22:25:58 |
emily | I wonder if this stuff is conditioned based on host or target platform 🙃 | 22:25:59 |
emily | (for e.g. Clang) | 22:26:15 |
emily | (uh, -I is definitely interpreted relative to $SDKROOT with Clang on Darwin, right?) | 22:26:42 |
Randy Eckenrode | Yes. | 22:27:23 |
Randy Eckenrode | I’m pretty sure. | 22:27:43 |
emily | it would be funny if the solution ends up being "ask toolchains to allow us to opt-in to the weird Darwin prefixing behaviour on other platforms". | 22:27:50 |
emily | don't ever say Darwin support does nothing for Nixpkgs! | 22:27:59 |
Artturin | https://github.com/NixOS/nixpkgs/pull/351768 | 22:48:34 |
emily | stdenv.__bootPackages.stdenv.__bootPackages.stdenv.__bootPackages.stdenv.__bootPackages … | 22:50:00 |
Artturin | Whoops that's for a separate commit 🤫 | 22:50:35 |
emily | it's too late. you made me see that and I'm not going to be able to sleep tonight | 22:50:56 |
emily | maybe we should expose something like this in the system interface – .emulator is constraint by having to be an actual executable, which is unfortunate when all you want to do is know how to adapt stuff. though I guess it only matters for sufficiently downstream stuff | 22:51:39 |
emily | we could just replace execline with a vendored package that's one line of C to call exec. | 22:51:52 |
emily | then execline wouldn't rebuild as much stuff and we wouldn't be adding any meaningful dependencies to .emulator use. | 22:52:20 |
emily | while keeping the uniform interface. | 22:52:34 |
Artturin | https://github.com/NixOS/nixpkgs/pull/324071 | 22:52:38 |
emily | yeah | 22:53:41 |
emily | but we don't need everything else in execline. | 22:53:47 |
emily | we don't even need its extra flags. | 22:54:02 |
emily | we can just write our own pkgs.exec or whatever. | 22:54:11 |
emily | (technically .emulator also behaves quite badly if you want to execute a program starting with a -, we should probably be wrapping that stuff) | 22:55:09 |
emily | oh, it looks like tie originally wrote that program and it got bikeshedded away. | 22:57:53 |
Artturin | I commented | 22:58:17 |
emily | right. well, Alyssa's proposal seems reasonable to me absent the closure size increase, I'm mostly just surprised that execline pulls in so much | 22:59:06 |
emily | considering it's a pile of barebones C | 22:59:09 |
emily | what does it pull in? it only seems to depend on skalibs. | 22:59:48 |
emily | which doesn't depend on anything. | 22:59:51 |
emily | ha, tie also pointed out the - thing | 23:00:45 |