Re: new rustc targets that don't match Debian architectures
On Wed, Nov 26, 2025, at 8:50 AM, Jan Niehusmann wrote:
> Hi Fabian,
>
> On Tue, Nov 25, 2025 at 05:44:13PM +0100, Fabian Grünbichler wrote:
>> 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..
>
> I don't know a better alternative right now, but it's likely that such a
> solution is only needed temporarily:
>
> With the build-std project goal
> (https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html),
> it should become possible to rebuild std for such targets on the fly,
> without the need of following obscure how-to guides.
>
> To be more specific, if I'm not mistaken, what's needed is the
> implementation of https://github.com/rust-lang/rfcs/pull/3874. When
> that's done, setting a single config option would suffice to enable
> building of the standard library for the target architecture.
>
> If some tweaks to these RFCs would be useful for debian to simplify
> support for cross-building, we should try to communicate that. The RFC
> process is meant to gather such feedback.
build-std (and build-core) already work for regular (non-packaging) cargo usage
with the packaged toolchain, the hack I was referring to is the need for
`RUSTC_BOOTSTRAP=1` and `-Zbuild-std` ;)
One downside to this is that for the package stdlibs, we take care to patch out
undesired things in the vendored crates (such as bundled C libraries that are
shipped as packages in Debian). Our rust-src package only ships the source
code and original lock files, and not those patched vendored crates - so if you
rebuild std or core you get a different set of crate versions and sometimes
contents.
I haven't yet found a good solution for this, because shipping the vendored
crates and modified Cargo.lock files has other issues (for one, the patching
also involves heavily pruning things which means some targets would not work at
all because their dependencies would bve pruned, but also there'd usually be
considerable overlap with the actual dependencies of whichever crate gets
compiled, which might result in incompatibilities).
Packaging "interesting" targets like the wasm and bpf ones allows using them in
both regular user and packaging contexts. But obviously we don't want to
package *all* the targets out there, e.g. most embedded targets will continue
to require build-std/core.
Fabian
Reply to: