[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new rustc targets that don't match Debian architectures



Hi Fabian,

On Tue, Nov 25, 2025 at 05:44:13PM +0100, Fabian Grünbichler wrote:
> rustc currently builds the Rust standard libraries (libcore, liballoc, libstd)
> for each of the supported Debian architectures, and additionally also for some
> wasm targets, shipped as `libstd-rust-dev-wasm32:all`. This package is :all
> because it doesn't match any of the existing Debian architectures, and rustc of
> any arch can use the resulting files to compile for the corresponding targets
> (currently `wasm32-unknown-unknown` aka browsers, and `wasm32-p1`/`wasm32-p2`
> which use `wasi-libc`, which is similarly "fake" :all).

There is significant established practice for using arch:all in this
way. Please also use M-A:foreign whenever you encode the ABI into the
binary package name.

> 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..

The tricky part here is the naming (i.e. the suffix). Please stay clear
from -$ARCH-cross, because that namespace assumes that $ARCH is an
actual Debian architecture and comes with some required semantics
attached.

Other than that, I wish there was more uniformity in Debian. I found a
number of suffixes for embedded targets:

 * -aarch64-linux-gnu (picolibc, arch:all)
 * -arm-none-eabi
 * -avr (there also is avr- as a prefix)
 * -efi (used with arch:any as kind of a sibling architecture)
 * -bpf
 * -djgpp
 * -h8300-hms
 * -m68hc1x
 * -mingw-w64-i686
 * -mingw-w64-ucrt64
 * -mingw-w64-x86-64
 * -or1k-elf 
 * -riscv64-unknown-elf
 * -sh-elf
 * wasi- (a prefix)
 * -wasm32
 * -wasm64
 * -xtensa-lx106
 * -z80 (for z80-unknown-coff)

As you can see, this is quite a mess. My plea is: When you add a suffix,
please research and try to increase consistency.

The other concern is when to use a proper Debian architecture.
Generally, I suggest that whenever there is a sensible chance that your
target can plausibly build a build-essential package set, it should
become a Debian architecture. And when that is implausible, it should
not. I consider all sorts of bpf and wasm not eligible. A not so obvious
Debian architecture would be musl-linux-any, which can be bootstrapped
until systemd.

Helmut


Reply to: