Failure in x.py test after updating to Rust 1.82 in the Yocto environment

1

The failure is happening because of a feature taken to rust_1.82 .

After updating to rust 1.82 , we ran "python3 src/bootstrap/bootstrap.py test" . Then we came across the below failure . Can anyone point me out do we need to make any changes in poky sources to adapt this feature or how to skip this test while running testsuite.

 Compiling rustc_driver_impl v0.0.0 (rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/compiler/rustc_driver_impl)
   Compiling rustc_driver v0.0.0 (rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/compiler/rustc_driver)
    Finished `release` profile [optimized] target(s) in 5m 29s
     Running unittests src/main.rs (build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/release/deps/rustc_main-92223b15c9f2d827)
uploaded "rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/release/deps/rustc_main-92223b15c9f2d827", waiting for result
/tmp/work/test4056/rustc_main-92223b15c9f2d827: error while loading shared libraries: librustc_driver-fb0866b1cd913c20.so: cannot open shared object file: No such file or directory
error: test failed, to rerun pass `-p rustc-main --bin rustc-main`

Caused by:
  process didn't exit successfully: `rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/remote-test-client run 0 rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/release/deps/rustc_main-92223b15c9f2d827 -Z unstable-options --format json` (exit status: 127)
note: test exited abnormally; to see the full output pass --nocapture to the harness.
     Running unittests src/lib.rs (build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/release/deps/rustc_abi-ec634b1002c52b95)
uploaded "rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/release/deps/rustc_abi-ec634b1002c52b95", waiting for result

running 1 tests
test tests::align_constants ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 34.99ms

As per my understanding , this feature makes rustc_driver statically link to std. Instead of using '-Z prefer_deps_of_dynamic' which will prevent linking to a dylib if there's a static variant of it already statically linked into another dylib dependency. But we used rustc_private feature. But I guess this feature is not working as intended. Please let us know if we are missing something .

Thanks in advance.

2

I wonder if for some reason the test runner forgets to upload rustc_driver.so to the target machine. Would you mind opening an issue?

3

Yes, I cannot able to find rustc_driver.so . But instead I can able find

fd "rustc_driver*"
librustc_driver-fb0866b1cd913c20.so
librustc_driver_impl-41ab001b5a5d6c41.rlib
librustc_driver_impl-41ab001b5a5d6c41.rmeta
rustc_driver-313f20049915b9d8
rustc_driver-313f20049915b9d8.d
rustc_driver-fb0866b1cd913c20.d
rustc_driver_impl-41ab001b5a5d6c41.d
rustc_driver_impl-c34a61fdcc10b86f
rustc_driver_impl-c34a61fdcc10b86f.d

in the below target directory as follows

rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/release/deps

I will open an issue and push the link here

And I have one more observation,

According to the above given error log, it seems like it cannot able to find the librustc_driver.so but I can able to find librustc_driver.so file in the following build path:

rust_1.82/tmp/work/core2-64-poky-linux/rust/1.82.0/rustc-1.82.0-src/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/release/deps

Using the fd command, I found the following files related to librustc_driver in that directory:

librustc_driver-fb0866b1cd913c20.so
librustc_driver_impl-41ab001b5a5d6c41.rlib
librustc_driver_impl-41ab001b5a5d6c41.rmeta

However, I am unsure about the path:

/tmp/work/test4056/rustc_main-92223b15c9f2d827

I'm not certain where this path is coming from, and whether it indicates that the system is trying to find the librustc_driver*.so file in the wrong location.

4

That is almost certainly the location to where on the test machine / test VM the test runner uploaded the rustc_main-92223b15c9f2d827 executable. Can you do ls -lR /tmp/work/test4056 on the test machine / test VM?