Re: new rustc targets that don't match Debian architectures
Adrian Bunk wrote:
> On Tue, Nov 25, 2025 at 11:28:48AM -0800, Josh Triplett wrote:
> >...
> > As a future example that will make this more complicated, in the future
> > we will have Rust targets that use `rustc_codgen_gcc` (AKA `cg_gcc`),
> > which uses `libgccjit` instead of LLVM. GCC doesn't do cross-compilation
> > the way LLVM does, and requires a *unique* build of GCC for every single
> > pair of (target, host). For those cases, I'd expect that those targets
> > will need to build :arch packages for every *host* :arch. For instance,
> > a `cg_gcc`-based target for the hypothetical xyz architecture would need
> > either a `libstd-rust-dev-xyz:all` or `libstd-rust-dev:xyz` package, but
> > it would *also* need a `librust-codegen-gcc-dev-xyz:amd64` package for
> > amd64 hosts, and an `librust-codegen-gcc-dev-xyz:aarch64` package for
> > aarch64 hosts.
> >
> > *That* is the case that makes me say this doesn't perfectly map onto
> > Debian architectures and sometimes requires putting the architecture
> > into the package name instead. I *think* that that problem wouldn't
> > exist if everything followed the LLVM model that doesn't require M*N
> > cross compilers for M hosts and N targtes.
>
> Either you are confusing something, or I am missing something.
>
> No matter whether you need M or M*N toolchain packages, these cannot
> be :all since they have to run on the host.
>
> No matter whether your toolchain is (target, host) or (any, host),
> the resulting binary will be for one specific target.
>
> Building an :arch package for an architecture other than the host
> architecture is not possible in Debian.
I should have been more explicit about distinguishing between the
packages that *can* be `:all` and the packages that *can't* be; sorry
for the sloppy handwaving. The *toolchain* packages can't be `:all` but
the *libraries for cross compiling* potentially can be if they don't
contain any code that needs to be run on the host.
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.
rustc's normal default backend, based on LLVM, has built-in support for
every target Rust supports. It needs a standard library for each target,
but it only needs to build *once* for each host architecture. Hence,
rustc is `:hostname` for each host architecture.
libgccjit and GCC-style toolchains need to be built once for each (host,
target) pair, and there's no current way around that.
(rustc_codegen_gcc, as it starts being shipped and scales to more
targets, will *hopefully* be built once per host, and just dlopen a
different libgccjit for each target.)
Reply to: