| 20 Jan 2025 |
 Tristan Ross | Gotcha | 19:14:40 |
| Tristan Ross | Maybe we have a base bootstrap that changes based on CC and adjusts things in later stages to accommodate for the other variables? | 19:15:27 |
 emily | you can compile GCC with Clang and Clang with GCC, right? so nominally the choice of bootstrap tools is independent of what compiler you want to use in the final environment, though in practice we likely have assumptions that break if they don't match (unlike cross bootstrap which inherently has to handle it - which is why unifying the two more would be good) | 19:26:17 |
| Tristan Ross | I'm not sure if GCC can be compiled with Clang, I know Clang can be compiled with LLVM. GNU things tend to not like Clang or LLVM stuff in certain cases. | 19:27:27 |
| Tristan Ross | * I'm not sure if GCC can be compiled with Clang, I know Clang can be compiled with GCC. GNU things tend to not like Clang or LLVM stuff in certain cases. | 19:27:38 |
 Randy Eckenrode | In reply to @emilazy:matrix.org
Randy Eckenrode's notion of native bootstrap as cross would help make bootstraps support more toolchains without causing a combinatorial explosion of special cases, I think I don’t think I’m the only one with this idea. I’m pretty sure there is an open issue about it. Ideally, it should be possible to have a fully functional stdenv from just the bootstrap tools, then you can cross-compile to your target platform from there.
One thing that may be problematic is cc-wrapper’s suffix salt. You want bootstrap tools, first build, and final build to be treated as different platforms in spite of having the same salt. I also don’t know how the final cc can be used to build everything but its own dependencies.
| 19:30:03 |
| Randy Eckenrode | One thing I would not mind is if the various pkgs reflected the stages of the bootstrap. | 19:30:46 |
| Randy Eckenrode | They don’t right nowz | 19:31:15 |
| Randy Eckenrode | * | 19:31:25 |
| emily | I feel like we ought to just use hashes for salts. | 19:32:22 |
| emily | same platform different salt shouldn't be possible. | 19:32:35 |
| Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
I'm not sure if GCC can be compiled with Clang, I know Clang can be compiled with GCC. GNU things tend to not like Clang or LLVM stuff in certain cases. Darwin builds GCC with Clang. | 19:33:14 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
same platform different salt shouldn't be possible. Static builds. Darwin needs a static-aware salt because the build SDK is dynamic while the host SDK is static. | 19:34:27 |
| Tristan Ross | In reply to @reckenrode:matrix.org
Darwin builds GCC with Clang. Oh, I wasn't aware of that. I just know from experience with pkgsLLVM there's quite a few cases of using the gccStdenv | 19:34:59 |
| emily | yeah. if GCC couldn't build Clang we'd have no Clang on Linux. if Clang couldn't build GCC we'd have no GCC on Darwin. | 19:39:28 |
| emily | since those are what we bootstrap from in practice | 19:39:37 |
| emily | In reply to @reckenrode:matrix.org
Static builds. Darwin needs a static-aware salt because the build SDK is dynamic while the host SDK is static. yeah. which is why it should just be a hash of the whole thing | 19:40:06 |
| Tristan Ross | After today's discussion, I'm really unsure the direction to go for the lib.systems PR. I can add the backwards compatibility bit but regarding toolchain, I just can't think of any alternatives. It's kinda needed so the other attributes default, it also makes using pkgsLLVM without specifying pkgs to NixOS easier. | 20:33:36 |
| emily | we can just require all the attributes to be set. defining platforms is rare and it's good to be explicit. pkgsLLVM can do the same, what problems do you envision there? | 20:50:18 |
| Tristan Ross | Maybe, I just think it's more convenient to have them inferred. | 20:52:12 |
| Tristan Ross | And we'll need to find cases where to replace *Platform.toolchain == with the appropriate case. | 20:54:22 |
| Tristan Ross | pkgs/development/compilers/llvm/common/compiler-rt/default.nix kinda needs it. | 20:55:17 |
| emily | it's more convenient in a very small handful of places but introduces a footgun everywhere | 20:55:19 |
| emily | which will ultimately make using alternative toolchains harder and more broken | 20:55:41 |
| Tristan Ross | Gotcha, maybe we use the backwards compatible use* until we can track down where things are and then switch the cases? | 20:56:31 |
| Tristan Ross | The use* would be based on the various attributes instead of the toolchain attribute. | 20:57:06 |
| Tristan Ross | So useLLVM checks if clang, compiler-rt, LLVM bintools, and libcxx are being used. | 20:57:34 |
| emily | we shouldn't use deprecated APIs in Nixpkgs - warnings will block the channel anyway | 20:58:35 |
| emily | surely it doesn't take more than a few minutes to just try building libseccomp with the various stdenvs and see which ones break? | 20:59:06 |
| emily | that needs narrowing down for an upstream report anyway | 20:59:36 |
