| 20 Jan 2025 |
 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 |
| Tristan Ross | In reply to @emilazy:matrix.org
surely it doesn't take more than a few minutes to just try building libseccomp with the various stdenvs and see which ones break? libseccomp isn't the only problem, nix also breaks, krb5 also has a funky case | 21:04:42 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/243249 this is also a funky case | 21:06:18 |
| emily | well, still. you can throw Clang + libstdc++, Clang + libc++, etc. at them and narrow it down. (I forget if GCC + libc++ is possible) | 21:06:45 |
| emily | In reply to @rosscomputerguy:matrix.org
https://github.com/NixOS/nixpkgs/pull/243249 this is also a funky case looks like a temporary hack. hopefully we can get rid of it. but it looks like it might be conditioning on a non-libgcc_s runtime library maybe | 21:07:58 |
