compile_test fails with non-nightly compiler

[mgorny]

I'm trying to package bpf-linker for Gentoo. As part of the packaging effort, we find it important to run tests to verify that the package works correctly. Currently, the test suite seems to fail hard with the production version of the Rust toolchain:

running 1 test
test compile_test ... FAILED

failures:

---- compile_test stdout ----
thread 'compile_test' panicked at tests/tests.rs:125:10:
failed to build sysroot: sysroot build failed; stderr:
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -Zforce-unstable-if-unmarked -Aunexpected_cfgs -Cdebuginfo=2 --target bpfel-unknown-none --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit status: 1)
  --- stderr
  error: the option `Z` is only accepted on the nightly compiler

  help: consider switching to a nightly toolchain: `rustup default nightly`

  note: selecting a toolchain with `+toolchain` arguments require a rustup proxy; see <https://rust-lang.github.io/rustup/concepts/index.html>

  note: for more information about Rust's stability policy, see <https://doc.rust-lang.org/book/appendix-07-nightly-rust.html#unstable-features>

  error: 1 nightly option were parsed



Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
             at /home/mgorny/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.95/src/backtrace.rs:27:14
   1: rustc_build_sysroot::SysrootBuilder::build_from_source
             at /home/mgorny/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustc-build-sysroot-0.5.4/src/lib.rs:498:17
   2: tests::compile_test
             at ./tests/tests.rs:118:11
   3: tests::compile_test::{{closure}}
             at ./tests/tests.rs:108:18
   4: core::ops::function::FnOnce::call_once
             at /usr/lib/rust/1.83.0/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
   5: test::__rust_begin_short_backtrace
   6: test::run_test::{{closure}}
   7: std::sys::backtrace::__rust_begin_short_backtrace
   8: core::ops::function::FnOnce::call_once{{vtable.shim}}
   9: std::sys::pal::unix::thread::Thread::new::thread_start
  10: <unknown>
  11: <unknown>
stack backtrace:
   0:     0x55ca95d6868a - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h708b1b3e1ab60c04
   1:     0x55ca95d91cd3 - core::fmt::write::ha65bb5788fe1ab12
   2:     0x55ca95d64a83 - std::io::Write::write_fmt::h5df9cba4a0285988
   3:     0x55ca95d684d2 - std::sys::backtrace::BacktraceLock::print::h44feac5061ff84fc
   4:     0x55ca95d6a16a - std::panicking::default_hook::{{closure}}::hbcb0c42bd1b5aec0
   5:     0x55ca95d69f74 - std::panicking::default_hook::h05165f4ad8043df6
   6:     0x55ca95d30239 - test::test_main::{{closure}}::h69b11b88471b54e9
   7:     0x55ca95d6a808 - std::panicking::rust_panic_with_hook::h7c861ee84a591477
   8:     0x55ca95d6a5ca - std::panicking::begin_panic_handler::{{closure}}::h750dce44a86dd82e
   9:     0x55ca95d68b69 - std::sys::backtrace::__rust_end_short_backtrace::h50d96c4e70f5e7cd
  10:     0x55ca95d6a25c - rust_begin_unwind
  11:     0x55ca9585b270 - core::panicking::panic_fmt::h2e3392a58e16b1c1
  12:     0x55ca9585b756 - core::result::unwrap_failed::hbeb9a6cfcd088ee9
  13:     0x55ca9585fd19 - core::result::Result<T,E>::expect::hf73e60f9b4bbc622
                               at /usr/lib/rust/1.83.0/lib/rustlib/src/rust/library/core/src/result.rs:1061:23
  14:     0x55ca9585dd8a - tests::compile_test::hf07922407c487b4e
                               at /tmp/bpf-linker/tests/tests.rs:118:11
  15:     0x55ca95864877 - tests::compile_test::{{closure}}::h99267a3c3179863b
                               at /tmp/bpf-linker/tests/tests.rs:108:18
  16:     0x55ca958655f6 - core::ops::function::FnOnce::call_once::h5e041177ef1ae212
                               at /usr/lib/rust/1.83.0/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
  17:     0x55ca95d34b4b - test::__rust_begin_short_backtrace::h430d9f48a8e955d6
  18:     0x55ca95d34437 - test::run_test::{{closure}}::hb1cdfc31a5509927
  19:     0x55ca95cf9714 - std::sys::backtrace::__rust_begin_short_backtrace::h492761d4e04a6126
  20:     0x55ca95cfcdde - core::ops::function::FnOnce::call_once{{vtable.shim}}::h08f62dbaf5c0beeb
  21:     0x55ca95d70d9b - std::sys::pal::unix::thread::Thread::new::thread_start::h812949c070527546
  22:     0x7f0e4c504f38 - <unknown>
  23:     0x7f0e4c58844c - <unknown>
  24:                0x0 - <unknown>


failures:
    compile_test

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.15s

Could you please either make the test work with production versions of the Rust compiler, or make it possible to skip it gracefully (e.g. via --features)?

[vadorovsky]

BPF is not a stabilized target in Rust, it's in Tier 3 and therefore available only in Rust nightly. So it's not even possible to compile BPF programs with stable Rust toolchains yet.

[mgorny]

Oh, do I understand correctly that this package can't work with stable Rust at all, and therefore mitmproxy just implicitly started requiring a nightly compiler?

[vadorovsky]

I don't know about mitmproxy, but if they are using Aya (on the eBPF side; using Aya just as a loader in user-space is possible with stable Rust) and bpf-linker, then yes, it requires a nightly compiler.

We were thinking about starting the process of stabilizing and moving the BPF target towards Tier 2 after adding a proper support of:

• BTF maps (feat(aya-ebpf): BTF maps aya#1117), which I would say I'm mostly done with, there are few integration tests I need to investigate and get some reviews.
• BTF relocations (Add BTF relocation support in eBPF programs aya#349), which is something I'm still working on.

And letting these features sink in and stabilize, before we declare 100% feature parity with libbpf.

But in case mitmproxy or any other well established project is already using Aya and that's blocking you from updating the package in Gentoo, then I think we should just ping the Rust community already and figure out whether we can move towards Tier 2 now.

Let me take a look at mitmproxy, I will think of what we can do.

[vadorovsky]

OK, yeah, this part needs Rust nightly https://github.com/mitmproxy/mitmproxy_rs/tree/main/mitmproxy-linux-ebpf

We have an open issue about stabilizing the target, #6, let's discuss it there. Do you mind if I close this one?