On Wed, Nov 26, 2025, at 8:50 AM, Jan Niehusmann wrote: > Hi Fabian, > > On Tue, Nov 25, 2025 at 05:44:13PM +0100, Fabian Grünbichler wrote: >> Is there a better way to handle this or is introducing a new :all package >> fine? >> Similar questions will arise in the future once 64-bit wasm stabilizes.. > > I don't know a better alternative right now, but it's likely that such a > solution is only needed temporarily: > > With the build-std project goal > (https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html), > it should become possible to rebuild std for such targets on the fly, > without the need of following obscure how-to guides. > > To be more specific, if I'm not mistaken, what's needed is the > implementation of https://github.com/rust-lang/rfcs/pull/3874. When > that's done, setting a single config option would suffice to enable > building of the standard library for the target architecture. > > If some tweaks to these RFCs would be useful for debian to simplify > support for cross-building, we should try to communicate that. The RFC > process is meant to gather such feedback.
build-std (and build-core) already work for regular (non-packaging) cargo usage with the packaged toolchain, the hack I was referring to is the need for `RUSTC_BOOTSTRAP=1` and `-Zbuild-std` ;) One downside to this is that for the package stdlibs, we take care to patch out undesired things in the vendored crates (such as bundled C libraries that are shipped as packages in Debian). Our rust-src package only ships the source code and original lock files, and not those patched vendored crates - so if you rebuild std or core you get a different set of crate versions and sometimes contents. I haven't yet found a good solution for this, because shipping the vendored crates and modified Cargo.lock files has other issues (for one, the patching also involves heavily pruning things which means some targets would not work at all because their dependencies would bve pruned, but also there'd usually be considerable overlap with the actual dependencies of whichever crate gets compiled, which might result in incompatibilities). Packaging "interesting" targets like the wasm and bpf ones allows using them in both regular user and packaging contexts. But obviously we don't want to package *all* the targets out there, e.g. most embedded targets will continue to require build-std/core. Fabian
