Nix Rust | 701 Members | |
| Rust | 157 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Jan 2026 | ||
| * It seems that mainline m1n1 doesn't build within nixpkgs, with the src overriden to this commit specifically https://github.com/HoolockLinux/m1n1/commit/19d973c873ad3f5396a23faaeb721b305b3d3cc1. It complains about a missing vendored uuid dependency and a missing .cargo-checksum.json. I'm not sure how to properly fix this since it is not using buildRustPackage because it uses a makefile with mixed C/Rust sources. Any ideas? | 21:01:21 | |
I figured it out. Using cargoRoot = "rust" + cargoDeps + fetchCargoVendor seems to work. | 21:06:52 | |
| 22:10:04 | ||
| i was looking through rust build infra in nixpkgs and found that lto is entirely opt in, which struct me as strange because lto=thin is the default for cargo and the rest of the rust ecosystem. is there a reason for this? | 22:15:04 | |
| i understand -O2 and no LTO by default for c/c++ packages since they could rely on UB that's broken by further optimization, but since the entire rust ecosystem defaults to -03 and thin lto (and rust programs usually don't violate the language's vm), it seems reasonable for that to be the default in nixpkgs as well | 22:18:17 | |
| Rust ecosystem does not default to -O3 | 22:21:14 | |
| Rust's optimization levels don't really map to C++ conventions | 22:21:23 | |
And even -C opt-level=3 is different from -O3 | 22:21:39 | |
| And no, Cargo does not default to thinlto | 22:22:24 | |
| https://doc.rust-lang.org/cargo/reference/profiles.html#release | 22:22:24 | |
| 22:22:39 | |
| oh I see | 22:28:03 | |
| sorry for the misunderstanding, I'm not sure where I read the thin lto by default thing | 22:28:31 | |
| the profiles page you linked to does say that lto=false is different from lto=off though, and that lto=false enables "thin local lto" | 22:29:54 | |
That should be our default as well, as I don't think we explicitly pass lto=false? | 22:39:17 | |
| i think we just inherit whatever upstream has profile.release set to? | 22:42:20 | |
| probably is? idk how rustc deals with default options | 22:42:21 | |
| * | 22:42:42 | |
| * | 22:43:12 | |
In reply to @k900:0upti.menever thought about this but I guess it's a good thing rust release builds don't use fast-math by default... | 22:44:11 | |
| i looked into this more and it seems thin local lto is redundant with codegen-units=1 anyway (and rustc disables thin local lto if codegen-units=1 and the lto level is unspecified) buildRustCrate has | 23:28:51 | |
| 18 Jan 2026 | ||
| dynamic derivations | 00:21:58 | |
| ? | 00:21:59 | |
| 20:43:40 | ||
| i get flashbacks to random segfaults in c/c++ when this happens:
💀 | 23:43:35 | |
| beginning to understand why the maintainer abandoned trying to update this package. somehow it compiles fine on darwin, but trying with aarch64 it throws this junk | 23:44:43 | |
| what are you trying to compile | 23:46:03 | |
| this one: https://github.com/NixOS/nixpkgs/blob/49213403e38ca893cafc83571d05bebbb782ff89/pkgs/by-name/st/stalwart-mail/package.nix | 23:48:12 | |
| think it might just be a local issue with vm, probably wont see this issue on hydra | 23:56:07 | |
| what signal was rustc terminated by | 23:56:56 | |