| 17 Dec 2024 |
 Randy Eckenrode | Ah, hmm. Those couple of Darwin-specific tools are potentially carrying a lot of weight. | 18:10:02 |
 Tristan Ross | Yeah | 18:10:13 |
| Randy Eckenrode | I’d definitely want to test and possibly do cleanup if Darwin were to use llvmPackages.bintools-unwrapped by default. | 18:10:50 |
| Randy Eckenrode | Based on my LLVM 19 testing, some stuff is still broken. | 18:11:13 |
| Randy Eckenrode | (As mentioned in the PR.) | 18:11:23 |
| Randy Eckenrode | Someone with Mach-O knowledge would need to fix install_name_tool. The same is probably true for lipo. | 18:12:08 |
| Randy Eckenrode | The other few cctools binaries probably don’t matter. Anyone who cares could add cctools manually. | 18:12:39 |
| Tristan Ross | Gotcha, yeah I can't test it atm but you could lol. Just adjust the linker or bintools in the local platform when importing nixpkgs and spin up a build | 18:16:16 |
| Randy Eckenrode | I know for sure regarding those particular tools because I tried to switch to the LLVM versions with the LLVM 19 update. | 18:25:54 |
| Randy Eckenrode | Those are the only two I have concerns about because they’re commonly used (especially by Meson). | 18:26:21 |
| Tristan Ross | Oh | 18:28:10 |
| Randy Eckenrode | When building a library in Meson, it sets the install name to @rpath/libfoo.dylib and the rpath to the build folder. When you install, it replaces all that with absolute paths. | 18:30:19 |
| Randy Eckenrode | Not sure about lipo, but I had to make it available unprefixed for cross-compilation to work. | 18:30:53 |
| Tristan Ross | Fun | 18:33:14 |
| Tristan Ross | I see there's a libc attribute in the platform stuff but where is that used? I'm wanting to hook up LLVM libc. | 19:20:54 |
| Randy Eckenrode | Isn’t it used in all-packages.nix to pick the libc package? | 19:55:47 |
| Randy Eckenrode | If only setting that were easy. Darwin gave up on it with the SDK rework. There are too many ways to capture the wrong libc version with multiple SDKs. | 19:56:38 |
| Tristan Ross | In reply to @reckenrode:matrix.org
Isn’t it used in all-packages.nix to pick the libc package? I'm not sure | 21:03:28 |
| Tristan Ross | I might have to probe it later lol | 21:03:49 |
 Artturin | It is | 22:07:48 |
| Artturin | https://github.com/NixOS/nixpkgs/blob/c91d5881387fe13e0e7b361861b099a6f52b2c03/pkgs/top-level/all-packages.nix#L9194 | 22:11:32 |
 Philip Taron (UTC-8) | I'm flexible. I would like to make the post on Discourse though. I see no one else has edited. I am happy to do that. | 22:49:15 |
| Tristan Ross | In reply to @artturin:matrix.org
https://github.com/NixOS/nixpkgs/blob/c91d5881387fe13e0e7b361861b099a6f52b2c03/pkgs/top-level/all-packages.nix#L9194 Oh, that's easy to hook up | 22:55:06 |
| Artturin | Its only cross, native is determined in the bootstrap | 23:01:27 |
| Tristan Ross | I might add a isDefaultToolchain attribute to detect if the toolchain, linker, bintools, libc, and cc options are the default. It'll make it easy to handle bootstrapping LLVM since it'll ensure nothing is switched weirdly. | 23:55:18 |
| 18 Dec 2024 |
|  @dmiskovic:matrix.org joined the room. | 19:38:09 |
| 19 Dec 2024 |
|  Alexandros Liarokapis joined the room. | 14:56:31 |
| Alexandros Liarokapis | Hi All. Is this correct?
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
dep(h0, t0, A, B)
propagated-dep(h1, t1, B, C)
h0 + h1 in {-1, 0, 1}
h0 + t1 in {-1, 0, -1}
----------------------------- Take immediate dependencies' propagated dependencies
propagated-dep(mapOffset(h0, t0, h1),
mapOffset(h0, t0, t1),
A, C)
``` ?
| 14:56:48 |
| Alexandros Liarokapis | shouldn't the final line be just dep instead of propagated-dep ? | 14:57:01 |
| Alexandros Liarokapis | because otherwise I think a propagatedBuildInputs would be propagated across a whole buildInputs chain. | 14:57:25 |
