On Tue, Nov 25, 2025, at 8:28 PM, Josh Triplett wrote: > 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.. > > :all seems like it might be the right way to handle this, since these > builds of `std` depend only on the *target* but doesn't depend at all on > the *host* architecture. If hypothetically we *had* some kind of wasm > target for Debian, we could potentially represent that as > `libstd-rust-dev:wasm32-wasip2`, but we don't have such targets, and > it's not *completely* obvious if the concepts map onto each other > perfectly. I *think* it works perfectly if everything acts like LLVM's > model for cross-compilation, but see below for cases that *don't* work > like that. > > By way of example, given the current architectures Debian has, the > mingw-based Rust targets you mentioned would *also* make sense to be > `:all`, because they don't actually depend on the host. In theory, we > could have an `x86_64-pc-windows-gnu` target for Debian, and have the > Rust mingw support be `libstd-rust-dev` for that `x86_64-pc-windows-gnu` > target. That would have some advantages, but again, it's not > *completely* obvious if the concepts map onto each other perfectly in > the non-LLVM model.
That's technically true, those could have been either :any or :all, since the mingw toolchains are available on all architectures. I think they were limited to amd64/i686 since it seemed like those are the likely architectures people compiling for Windows would run anyway, and it meant not needing to cross-compile the stdlib :) > As a future example that will make this more complicated, in the future > we will have Rust targets that use `rustc_codgen_gcc` (AKA `cg_gcc`), > which uses `libgccjit` instead of LLVM. GCC doesn't do cross-compilation > the way LLVM does, and requires a *unique* build of GCC for every single > pair of (target, host). For those cases, I'd expect that those targets > will need to build :arch packages for every *host* :arch. For instance, > a `cg_gcc`-based target for the hypothetical xyz architecture would need > either a `libstd-rust-dev-xyz:all` or `libstd-rust-dev:xyz` package, but > it would *also* need a `librust-codegen-gcc-dev-xyz:amd64` package for > amd64 hosts, and an `librust-codegen-gcc-dev-xyz:aarch64` package for > aarch64 hosts. Yes, rustc_codegen_gcc will be interesting for sure! we will likely have to have wrappers for each arch and -for-host/-for-build. But it will be a bridge we will cross at some point the future! > *That* is the case that makes me say this doesn't perfectly map onto > Debian architectures and sometimes requires putting the architecture > into the package name instead. I *think* that that problem wouldn't > exist if everything followed the LLVM model that doesn't require M*N > cross compilers for M hosts and N targtes.
