new rustc targets that don't match Debian architectures
Hi!
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).
We also used to ship windows standard libs built via the mingw toolchain, but
those were dropped in Trixie (and those were not :all anyway, but mapped to
amd64/i386).
I would like to introduce new packages for (Tier 3) BPF targets
`bpfeb-unknown-none` and `bpfel-unknown-none`, to support use cases like aya-rs
properly. These exist in a similar void like the wasm ones - they don't really
match any of the Debian architectures, and rustc can build and use them on any
build architecture. Obviously with the caveat that endianness matters here, so
you need to select the right variant of the target matching the platform you
want to run the compiled BPF bytecode on.
Currently users that want to use those targets with the packaged toolchain need
hacks to enable building libcore from scratch for that target, which in turn
means a lot of guides push people to use rustup and nightly toolchains, even
though the packaged one would work fine if it would ship a pre-compiled
libcore.
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..
Would be happy to get input,
Fabian
Reply to: