| 20 Jan 2025 |
 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 |
| emily | though if it works with FreeBSD but not those even today then maybe not | 21:08:20 |
| Tristan Ross | In reply to @emilazy:matrix.org
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 Gotcha, so we can narrow it to the rtlib option instead of needing toolchain for this specific case? | 21:08:52 |
| Tristan Ross | I wonder how we should handle the Rust stuff in this PR. | 21:10:40 |
| Tristan Ross | In reply to @emilazy:matrix.org
well, still. you can throw Clang + libstdc++, Clang + libc++, etc. at them and narrow it down. (I forget if GCC + libc++ is possible) Oh fun, cxxlib isn't really wired up. Will have to figure out how to do that so I can test that. | 21:13:31 |
| emily | we already have stdenv for Clang and Clang + libc++ | 21:14:35 |
| emily | clangStdenv etc | 21:14:40 |
| emily | but we should probably also wire up the variables we're adding... :) | 21:14:59 |
| emily | In reply to @rosscomputerguy:matrix.org
Gotcha, so we can narrow it to the rtlib option instead of needing toolchain for this specific case? it'd need testing, but maybe. first I'd try just removing altogether | 21:15:16 |
| Tristan Ross | In reply to @emilazy:matrix.org
but we should probably also wire up the variables we're adding... :) Yeah, that's going to be fun figuring out. | 21:15:41 |
| emily | Tristan Ross: if you want to land this incrementally, my recommendation is:
- add the new variables solely as output-only, i.e., derive them from the existing
useLLVM etc. and assert that they are not set to anything contradicting those
- get rid of everything that looks at
useLLVM and so on in-tree, making them use the more precise variables instead
- make sure the bootstrap respects them and everything is wired up correctly (this should mostly be a matter of fixing existing conditionals on things like
useLLVM to determine what C++ library to set up and so on, I think; the various Clang stdenvs should help there)
- then, allow the variables to vary freely and start the deprecation of
useLLVM etc.
| 22:07:16 |
| emily | as far as Rust goes, it's pretty hopelessly confused about cross-compilation / LLVM right now, so we will need rhelmot's PR and probably some additional work on top of that | 22:07:25 |
| 21 Jan 2025 |
| Tristan Ross | emily: How should we handle default values without using toolchain? Make everything null or should everything check what the platform is then set based on that? | 02:18:38 |
| emily | if following the incremental plan, everything would initially default to the value it currently has based on useLLVM etc. (and assert if anyone tries to specify something mismatching), and then in the final step they would become mandatory to set if not using the useLLVM back-compatibility shim | 02:21:01 |
| emily | (though presumably null is fine for freestanding platforms that don't care) | 02:21:08 |
| Tristan Ross | Oh | 02:21:41 |
| emily | (defaulting based on platform is probably fine too although ideally we wouldn't assume that x86_64-linux means GCC etc. in the long run) | 02:25:42 |
| Tristan Ross | If I want multiple lib.warnIf with the oldest supported release thing, I could use lib.pipe so I don't have to put things in parentheses? | 02:31:13 |
| emily | I use assert …; for that stuff. but I think you'd want to get things wired up before actually expecting people to set it per ^, otherwise it'll be one very big PR | 02:32:39 |
| Tristan Ross | Oh | 02:32:52 |
| Tristan Ross | It wouldn't even take effect until 25.11 | 02:33:36 |
| emily | well, ideally we can get the prep done before the 25.05 release :) | 02:36:59 |
| emily | splitting it up will probably help with that | 02:37:11 |
| Tristan Ross | Yeah | 02:37:22 |
| Tristan Ross | Ok, the "legacy" use* has been wired up to set the new attributes and pkgsLLVM looks to work with that | 02:37:50 |
