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

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



On Thu, Nov 27, 2025 at 07:07:28PM +0100, Helmut Grohne wrote:
>...
> 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.
>...

Which is not particularly relevant when building an architecture 
ecosystem in arch:all would prevent providing security support.

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

hurd-i386 and hurd-amd64 are proper Debian architectures without systemd.
Yocto even has (not upstreamable) changes to make systemd work with musl.

But the problem with using a proper Debian architecture is that this
would not be a release architecture, like the only bits of x32 available 
for our users are multilib since the architecture in ports is not a 
release architecture.

> Helmut

cu
Adrian


Reply to: