| 17 Dec 2024 |
 Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
Wdym by updating the LLVM build? I was thinking it needed more granularity like if a platform used LLVM bintools, it would default to building them in the LLVM build like it does currently when useLLVM. | 18:00:30 |
 Tristan Ross | Oh gotcha | 18:01:21 |
| Randy Eckenrode | That seems like something to do in a follow up. | 18:01:45 |
| Tristan Ross | Yeah | 18:01:56 |
| Randy Eckenrode | If you can get away with setting bintools to llvm on Darwin now, I’d say go for it. Otherwise, if it requires cleanup, I say do it separately. | 18:02:28 |
| Tristan Ross | I'm not sure if it'll require a cleanup | 18:02:50 |
| Tristan Ross | I don't have time to test atm and I don't do much on Darwin. | 18:03:22 |
| Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
I'm not sure if it'll require a cleanup Not sure either. If nothing is being changes to check bintools, then probably not. | 18:04:51 |
| Tristan Ross | Stuff does check it | 18:05:09 |
| Tristan Ross | The bintools derivation in nixpkgs itself | 18:05:21 |
| Tristan Ross | It's an alias which changes based on linker and bintools in the platform | 18:05:40 |
| Tristan Ross | Plan is to make that only change on bintools in the platform | 18:06:04 |
| Randy Eckenrode | I don’t see that in the PR? | 18:07:19 |
| Randy Eckenrode | Oh, there it is in all-packages.nix. | 18:07:49 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/365057/files#diff-ab5748dc9567516fefba8344056b51ec1866adeace380f46e58a7af3d619ea22R7903 | 18:08:04 |
| 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 |
