aya-build: enable -Zbuild-std=core when RUSTC_BOOTSTRAP is set

[miroslavhruz]

Problem

When building in environments that don't have rustup (e.g. Yocto/OpenEmbedded, Buildroot, other embedded Linux build systems), aya-build correctly falls back to invoking cargo directly.
However, since these systems ship a stable rustc, the channel check:

if channel == Channel::Nightly {
cmd.args(["-Z", "build-std=core"]);
}

evaluates to false, and -Zbuild-std=core is never passed. Building for bpfel-unknown-none (a tier-3 target with no pre-built standard library) then fails:

error[E0463]: can't find crate for core
= note: the bpfel-unknown-none target may not be installed
= help: consider building the standard library from source with cargo build -Zbuild-std

Solution

Embedded build systems commonly set RUSTC_BOOTSTRAP=1 to allow stable rustc to use unstable features. This is an established convention (also used in the compiler's own bootstrap
process) that signals "this toolchain can use nightly features".

When RUSTC_BOOTSTRAP is set, also pass -Zbuild-std=core:

if channel == Channel::Nightly || env::var_os("RUSTC_BOOTSTRAP").is_some() {
cmd.args(["-Z", "build-std=core"]);
}

Testing

Verified in a Yocto cross-compilation environment building for aarch64-unknown-linux-gnu with bpfel-unknown-none as the eBPF target.

---

This change is 

[netlify]

✅ Deploy Preview for aya-rs-docs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	2fede48
🔍 Latest deploy log	https://app.netlify.com/projects/aya-rs-docs/deploys/69ae7b044851ea0008af0387
😎 Deploy Preview	https://deploy-preview-1491--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[vadorovsky]

I agree with adding this change for consistency (after addressing my inline comment).

I just want you to know that if your goal is to add Aya support with stable Rust toolchains in Yocto/OpenEmbedded, there is a better way than setting RUSTC_BOOSTRAP=1. A cleaner solution is to build these stable Rust toolchains with BPF targets enabled.

We are doing the following trick in Gentoo:

https://github.com/gentoo/gentoo/blob/f363f98d6a19453a397af537f7102d59e431a1ad/dev-lang/rust/rust-1.93.1.ebuild#L385-L387

which basically nails down to adding bpfeb-unknown-none and bpfel-unknown-none to the

[build]
target = ...

part of bootstrap.toml.

Same is done in NixOS:

https://github.com/NixOS/nixpkgs/blob/182bcd0c1f24f6518590fffb12e0e2fafa57efdc/pkgs/development/compilers/rust/rustc.nix#L156-L157

[vadorovsky]

We should check if the value is actually 1.

We should also skip adding these arguments if the value is -1, because according to the docs:

Setting RUSTC_BOOTSTRAP=-1 instructs rustc to act as if it is a stable compiler, even on the nightly release channel.

[tamird]

In addition to @vadorovsky's comments

This is an established convention (also used in the compiler's own bootstrap
process) that signals "this toolchain can use nightly features".

is just not true. It's a hack. It might be fine to do here but let's call it what it is, even if LLMs want to pretend otherwise.

[miroslavhruz]

Fixed the code according the review.

Yes the code was made by AI, but we found the variable on the internet. we are using rustbin from meta-rust-bin layer, not compiling rust from sources. So the pointed out solution from gentoo we can't apply easily.

Made also that check by the crate name, as it was mentioned in the documentation.

Thanks

[tamird]

Fixed the code according the review.

Yes the code was made by AI, but we found the variable on the internet. we are using rustbin from meta-rust-bin layer, not compiling rust from sources. So the pointed out solution from gentoo we can't apply easily.

Made also that check by the crate name, as it was mentioned in the documentation.

Please add a citation in the code, this is quite surprising for a casual reader.