Re: new rustc targets that don't match Debian architectures
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.
Reply to: