On Sun, Apr 13, 2025, at 9:45 PM, Matt Corallo wrote: > On 4/7/25 3:47 PM, Fabian Grünbichler wrote: >> That's bookworm, the version with the fix came later, Trixie/did ship the >> Cargo.lock file: > > Ha, apologies, I'd filed this against the wrong version. Glad its fixed > in trixie, at least. > >> >>>> note that this lock file includes a lot of things that we actually >>>> remove when doing the package build, and versions might not line up >>>> 100% as a result, so it is possible for this to fail still or be >>>> buggy. >>>> >>>> shipping the actually used Cargo.lock file would require also shipping >>>> a copy of all the vendored crates used for the build in their patched >>>> form (since those would be referenced by that Cargo.lock file), and >>>> configuring the build to use it (at least for building core and std and >>>> friends). >>> >>> Specifically, my issue is that building with the above command results in >>> failures because cargo pulls the latest `compiler-builtins` when building >>> with -Zbuild-std which fails to build (as compiler-builtins is only >>> supported for a specific version of rustc). A Cargo.lock should enable >>> rustc to pin `compiler-builtins`, I imagine. >>> >>>> you can likely manually achieve such a setup by downloading the rustc >>>> source package and modifying it to build a toolchain and libstd for >>>> your desired target. >>> >>> If this is required maybe debian should be shipping for way more platforms? >> >> That's not really possible/in scope for Debian.. > > I don't see why? Debian already ships libstd-rust-dev-windows as well > as gcc packages for tons of > random targets, but really I guess this is just #989844, then.
most such targets don't really have a clear mapping to Debian architectures, and also no use case within Debian. the windows one is no longer built (by default, the support is still there in case somebody needs it) because the windows-cross toolchain it uses produces unreproducible output.
