Re: new rustc targets that don't match Debian architectures
On Wed, Nov 26, 2025 at 12:32:40AM +0200, Adrian Bunk wrote:
> On Tue, Nov 25, 2025 at 01:46:04PM -0800, Josh Triplett wrote:
> > Packages of the Rust standard library (`std`) don't care what the host
> > is; they *only* care what the target is. They could reasonably be either
> > `librust-std-dev-targetname:all` or `librust-std-dev:targetname`; either
> > one works, it's just that the latter requires the architecture to be
> > enabled on the system in order to depend on it.
>
> `librust-std-dev:targetname` does not work in Debian unless targetname
> is the host architecture. And when targetname is not a Debian release
> architecture, then that's really far outside of what could work.
First of all, let me be explicit that I'm talking about what *could* be,
not what *is*. Some of it is possible today, some of it isn't. With that
said:
It could work fine for cross-compilation using multi-arch, which is
something Debian does wildly better than many other distributions. That
may not work on buildds (I don't know to what extent buildds have any
support for the equivalent of `dpkg --add-architecture`), but it *could*
in theory, and similar things work fine when building packages locally.
For instance, today, I can install `musl-dev:arm64` on my amd64 system,
*without* qemu-user, and use that to successfully build Rust crates
targeting the `aarch64-unknown-linux-musl` target that want to compile C
code.
There is no *inherent* reason for a difference between "the build of
libstd-rust-dev for arm64 to use natively" and "the build of
libstd-rust-dev for cross-compilation to arm64". (There may be
logistical considerations, but those could be solved.)
`libstd-rust-dev`[1] is `Multi-Arch: same`, which is co-installable, and
there's nothing inherent that would make it impossible to support a
workflow using this to cross-compile. Instead of someone installing
rustup and using `rustup target add xyz`, someone could install
`libstd-rust-dev:xyz` and then use Debian's rustc with `--target xyz`
(modulo naming differences, and making sure the sysroots get found in
the right place). For Debian architectures, `libstd-rust-dev` will also
pull in `libstd-rust-${version}`, which won't *run* on the host, but
it's perfectly suitable for linking against.
[1] Got the name backwards earlier, it's `libstd-rust-dev` not
`librust-std-dev`.
If some project (e.g. a hypothetical Linux emulator) needed to
cross-compile some binaries for amd64 and arm64, this would be a
perfectly sensible way to do it, without having to use rustup or obtain
things from outside Debian.
This seems strictly better than, for instance, having a
`libstd-rust-dev-arm64` package and a `libstd-rust-dev-amd64` package
and so on. Though, as you noted, it wouldn't work so well right now for
architectures Debian doesn't support and for which most packages make no
sense to build (e.g. bpf or wasm targets). For those, the path of least
resistance right now is certainly a `libstd-rust-dev-targetname`
package.
Obviously, there's no *inherent* reason why `libstd-rust-dev-arm64:all`
wouldn't work, but it seems needlessly duplicative.
[snipping unrelated claims about security to avoid arguing about them
here]
> :all would currently [...] exclude the package from proper security
> support due to lack of binNMUs for :all.
It would be lovely to fix that, sure. One way to do that would be to
support binNMUs for `:all`. Another would be to use the "correct"
architecture, since there is no *inherent* reason for a difference
between "the build of libstd-rust-dev for arm64 to use natively" and
"the build of libstd-rust-dev for cross-compilation to arm64".
> From maintainer and user point of views `librust-std-dev-targetname:all`
> and `librust-std-dev-targetname:host` are nearly identical, so that's
> not a big issue.
Sure; it's mostly just a waste of storage space.
Reply to: