| 11 Nov 2024 |
emily | In reply to @reckenrode:matrix.org Darwin doesn’t need rpaths set though. How to handle that when Darwin is the target platform? it's just a default for ld-wrapper, right? so it can go in the ld-wrapper derivation? | 22:12:15 |
emily | I guess that would still rebuild the world though. | 22:12:32 |
emily | it might just need patching in ld64. | 22:12:43 |
sterni | Randy Eckenrode: it should be moved into the cc wrapper somehow since then we can be sure that target is relevant | 22:12:45 |
sterni | can probably be put in its setup hook | 22:12:53 |
sterni | or maybe binutils | 22:12:57 |
emily | what's a binutils? :) | 22:13:16 |
Randy Eckenrode | In reply to @emilazy:matrix.org it might just need patching in ld64. Why would ld64 need patching? There’s nothing wrong with it. | 22:13:23 |
emily | In reply to @reckenrode:matrix.org Why would ld64 need patching? There’s nothing wrong with it. well, since it would mean fewer things changing depending on stdenv.targetPlatform. | 22:13:49 |
emily | but it might not be the right place. probably the wrapper is a better idea. (but then adjusting the target platform would still result in rebuilds, right?) | 22:14:05 |
emily | (really need targetPlatform = null…) | 22:14:31 |
Randy Eckenrode | I have two main concerns:
- Darwin is not forced to be like other platforms for the sake of convenience. We’re finally undoing a lot of that after the refactor; and
- Darwin tooling is not hacked up to work around number 1.
| 22:15:53 |
emily | I think it's more about a general principle that targetPlatform differences should not cause rebuilds of things that don't care about targetPlatform | 22:16:49 |
emily | whereas currently targetPlatform being Darwin or not rebuilds the world | 22:16:59 |
emily | in an ideal world the unwrapped LLVM derivation wouldn't even be able to look at targetPlatform, e.g. | 22:17:28 |
emily | currently, rg 'targetPlatform\.is' pkgs/stdenv is two Darwins and two ghcjses | 22:18:36 |
emily | (one of the Darwins is harmless, just making makeStaticBinaries throw) | 22:18:57 |
emily | (and the ghcjs mentions also look harmless) | 22:19:12 |
Randy Eckenrode | So if we can move this to the wrapper, that seems fine. | 22:21:14 |
Randy Eckenrode | In reply to @emilazy:matrix.org whereas currently targetPlatform being Darwin or not rebuilds the world That seems to be a Nix problem where any change in puts cause rebuilds even when they don’t matter. | 22:21:34 |
Randy Eckenrode | In reply to @emilazy:matrix.org whereas currently targetPlatform being Darwin or not rebuilds the world * | 22:22:05 |
Randy Eckenrode | But anyway, to solve the problem at hand, if we can move it somewhere else to avoid the rebuilds, that’s fine. | 22:22:19 |
emily | it seems like the wrapper would still cause rebuilds because ld-wrapper is used to build clang-unwrapped, etc., but maybe I don't fully understand the rebuild issue | 22:23:28 |
emily | In reply to @reckenrode:matrix.org That seems to be a Nix problem where any change in inputs cause rebuilds even when they don’t matter. a problem that the solution to breaks Darwin in other ways… | 22:23:49 |
Randy Eckenrode | In reply to @emilazy:matrix.org it seems like the wrapper would still cause rebuilds because ld-wrapper is used to build clang-unwrapped, etc., but maybe I don't fully understand the rebuild issue If you’re using a different linker, I’d expect clang-unwrapped to be rebuilt. There’s no avoiding that. | 22:24:29 |
emily | well, the linker wouldn't matter, since it's only for the target platform | 22:25:52 |
emily | but hm | 22:25:54 |
emily | is ld-wrapper different for the target linker vs. the host one? | 22:26:12 |
emily | I guess it must be? | 22:26:14 |
emily | in which case yeah I guess we can move it in there. | 22:26:20 |