Re: new rustc targets that don't match Debian architectures
On Tue, Nov 25, 2025, at 11:32 PM, 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.
I am not sure whether you are using the same host/target terms here ;)
When Josh writes "host" above, it is what GNU/dpkg call "build". When Josh
writes "target", that is what GNU call "host" or "target".
So yes, in theory we could build the stdlib as arch:all package for all
architectures, but that doesn't make much sense since we also want to build and
ship a toolchain for most of them anyway, so for those we build
toolchain+stdlib in one go as a native build. The resulting stdlib packages can
then be used via M-A to do cross-compilation, without requiring a separate
toolchain for that target, the "native" can use all those stdlibs for all
targets to compile for those targets.
$ cd /tmp
$ cargo init foobar && cd foobar
Creating binary (application) package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
$ sudo dpkg --print-architecture
amd64
$ sudo dpkg --print-foreign-architectures
$ sudo dpkg --add-architecture arm64
$ sudo apt update
[..]
$ sudo apt install libstd-rust-dev:arm64 gcc-15-aarch64-linux-gnu
[..]
Installing dependencies:
gcc-15-base:arm64 libedit2:arm64 libidn2-0:arm64 libstd-rust-1.90:arm64 libunistring5:arm64 libzstd1:arm64
libbsd0:arm64 libffi8:arm64 libllvm19:arm64 libstdc++6:arm64 libxml2-16:arm64 zlib1g:arm64
libc6:arm64 libgcc-s1:arm64 libmd0:arm64 libtinfo6:arm64 libz3-4:arm64
[..]
$ cargo add anyhow
Updating crates.io index
Adding anyhow v1.0.100 to dependencies
Features:
+ std
- backtrace
Updating crates.io index
Locking 1 package to latest Rust 1.90.0 compatible version
Adding anyhow v1.0.100
$ RUSTFLAGS='-C linker=aarch64-linux-gnu-gcc-15' cargo build --release --target aarch64-unknown-linux-gnu
Compiling anyhow v1.0.100
Compiling foobar v0.1.0 (/tmp/foobar)
Finished `release` profile [optimized] target(s) in 0.83s
$ file target/aarch64-unknown-linux-gnu/release/foobar
target/aarch64-unknown-linux-gnu/release/foobar: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=4ee33a931fa7f9a02c1f04ecb89a7259f507a322, for GNU/Linux 3.7.0, not stripped
We can even rebuild the stdlib on the fly via rust-src (although the result
will not be identical to the shipped one, since this will fetch dependencies
from crates.io):
$ RUSTFLAGS='-C linker=aarch64-linux-gnu-gcc-15' RUSTC_BOOTSTRAP=1 cargo build -Zbuild-std --release --target aarch64-unknown-linux-gnu
Downloaded rustc-demangle v0.1.25
Downloaded addr2line v0.25.0
Downloaded gimli v0.32.0
Downloaded object v0.37.1
Downloaded 4 crates (680.9KiB) in 0.83s
Compiling compiler_builtins v0.1.160 (/usr/lib/rustlib/src/rust/library/compiler-builtins/compiler-builtins)
Compiling core v0.0.0 (/usr/lib/rustlib/src/rust/library/core)
Compiling libc v0.2.174
Compiling object v0.37.1
Compiling std v0.0.0 (/usr/lib/rustlib/src/rust/library/std)
Compiling anyhow v1.0.100
Compiling rustc-std-workspace-core v1.99.0 (/usr/lib/rustlib/src/rust/library/rustc-std-workspace-core)
Compiling alloc v0.0.0 (/usr/lib/rustlib/src/rust/library/alloc)
Compiling cfg-if v1.0.1
Compiling memchr v2.7.5
Compiling adler2 v2.0.1
Compiling panic_abort v0.0.0 (/usr/lib/rustlib/src/rust/library/panic_abort)
Compiling rustc-demangle v0.1.25
Compiling unwind v0.0.0 (/usr/lib/rustlib/src/rust/library/unwind)
Compiling rustc-std-workspace-alloc v1.99.0 (/usr/lib/rustlib/src/rust/library/rustc-std-workspace-alloc)
Compiling std_detect v0.1.5 (/usr/lib/rustlib/src/rust/library/std_detect)
Compiling panic_unwind v0.0.0 (/usr/lib/rustlib/src/rust/library/panic_unwind)
Compiling gimli v0.32.0
Compiling miniz_oxide v0.8.9
Compiling hashbrown v0.15.4
Compiling addr2line v0.25.0
Compiling rustc-std-workspace-std v1.99.0 (/usr/lib/rustlib/src/rust/library/rustc-std-workspace-std)
Compiling rustc-literal-escaper v0.0.5
Compiling proc_macro v0.0.0 (/usr/lib/rustlib/src/rust/library/proc_macro)
Compiling foobar v0.1.0 (/tmp/foobar)
Finished `release` profile [optimized] target(s) in 21.50s
But indeed, for those targets that don't have an equivalent single Debian
architecture, that is moot. Hence this thread, where the question is:
- build them as :all (save build time and space, but no binNMU)
- build them on each arch as :any (waste build time and space, but binNMUs)
>
> The options available are `librust-std-dev-targetname:all` or
> `librust-std-dev-targetname:host`.
>
> Security does not seem to be a high priority for proponents of more Rust
> in Debian, but when that gets sorted out then :all would currently still
> exclude the package from proper security support due to lack of binNMUs
> for :all.
Well, there are plenty of :all packages which are covered by security support.
I suspect if there is an issue in the stdlib we'd do a sourceful upload anyway,
and not a binNMU (and rather then binNMU all the things statically linking
libstd ;)).
> What works and might realistically be security-supported in Debian 14
> is `librust-std-dev-targetname:host`.
>
>>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.
I agree that both work in principle, the question is rather which one is
prefered. And then the follow-up question would be whether we'd want to switch
over wasi-libc and the wasm stdlib, if the consensus is that :any (or what you
call :host) would be best.
Reply to: