error_index_generator stage 0 tests don't work with download-ci-llvm: "error while loading shared libraries: libLLVM-11-rust-1.49.0-nightly.so"

[jyn514]

command did not execute successfully: "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0-tools-bin/error_index_generator" "markdown" "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/test/error-index.md"
expected success, got: exit code: 127

stdout ----

stderr ----
/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0-tools-bin/error_index_generator: error while loading shared libraries: libLLVM-11-rust-1.49.0-nightly.so: cannot open shared object file: No such file or directory

failed to run: /home/joshua/rustc/build/bootstrap/debug/bootstrap test --stage 0 src/tools/error_index_generator/

[jyn514]

I have download-ci-llvm = "if-available" in case that makes a difference.

[RalfJung]

Miri also runs into this when doing x.py test --stage 0 src/tools/miri (which used to work)

[jyn514]

From zulip:

I think the fix is indeed that these tools should not be run without being in the sysroot.

[Michael-F-Bryan]

@jyn514 I believe this may have been resolved some time between the issue being created and now. When i tried to reproduce it locally (a4cbb44) the error index tests were able to start and run just fine.

The tests failed with "error[E0658]: const generics are unstable" because some snippets use #![feature(const_generics)] instead of the recently stabilised min_const_generics, but that doesn't have anything to do with being unable to load shared libraries. Similarly I was able to run x.py test --stage 0 src/tools/miri without an issue.

@jyn514 and @RalfJung are you still able to reproduce this?

[RalfJung]

Similarly I was able to run x.py test --stage 0 src/tools/miri without an issue.

I just tried this and it still fails:

     Running `build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/cargo-miri miri setup`
thread 'main' panicked at 'failed to determine underlying rustc version of Miri: UnexpectedVersionFormat', src/tools/miri/cargo-miri/bin.rs:132:38
stack backtrace:
   0: rust_begin_unwind
             at ./library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at ./library/core/src/panicking.rs:92:14
   2: core::option::expect_none_failed
             at ./library/core/src/option.rs:1266:5
   3: core::result::Result<T,E>::expect
             at ./library/core/src/result.rs:929:23
   4: cargo_miri::version_info
             at ./src/tools/miri/cargo-miri/bin.rs:132:5
   5: cargo_miri::setup
             at ./src/tools/miri/cargo-miri/bin.rs:325:16
   6: cargo_miri::phase_cargo_miri
             at ./src/tools/miri/cargo-miri/bin.rs:418:5
   7: cargo_miri::main
             at ./src/tools/miri/cargo-miri/bin.rs:757:25
   8: core::ops::function::FnOnce::call_once
             at ./library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I haven't checked, but I assume the "incorrect version format" is precisely because there's still some error such as "cannot open shared object file" being reported. (That's what used to happen.)

Note that I have download-ci-llvm = true; maybe that's important to reproduce the problem.

[Michael-F-Bryan]

Note that I have download-ci-llvm = true; maybe that's important to reproduce the problem.

It looks like download-ci-llvm has something to do with this because when I switched to download-ci-llvm = true I also got the same "incorrect version format" error.

I haven't checked, but I assume the "incorrect version format" is precisely because there's still some error such as "cannot open shared object file" being reported. (That's what used to happen.)

I printed the output of rustc -vV (here) and apparently rustc doesn't generate any output. I'm not sure if that is relevant.

[/home/michael/.cargo/registry/src/github.spider-man.dpdns.org-1ecc6299db9ec823/rustc_version-0.2.3/src/lib.rs:112] str::from_utf8(&out.stdout) = Ok(
    "",
)

[RalfJung]

I printed the output of rustc -vV (here) and apparently rustc doesn't generate any output. I'm not sure if that is relevant.

That's stdout; what does stderr say?

[Michael-F-Bryan]

Ah yep, it's the "unable to load shared libraries" error message:

[/home/michael/.cargo/registry/src/github.spider-man.dpdns.org-1ecc6299db9ec823/rustc_version-0.2.3/src/lib.rs:112] str::from_utf8(&out.stderr) = Ok(
    "/home/michael/Documents/forks/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/miri: error while loading shared libraries: libLLVM-11-rust-1.51.0-nightly.so: cannot open shared object file: No such file or directory\n",
)

[Michael-F-Bryan]

Inspecting the failing miri binary shows it isn't able to find rustc-driver or std:

$ ldd build/x86_64-unknown-linux-gnu/stage0-tools-bin/miri
	linux-vdso.so.1 (0x00007ffeac5f7000)
	librustc_driver-110e2444bfbc1fba.so => not found
	libstd-6593c2e4e017f5fb.so => not found
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f0f3d890000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f0f3d86e000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f0f3d728000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f0f3d55f000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f0f3dced000)

Should bootstrap be fiddling with LD_LIBRARY_PATH or setting rpath when compiling/running? I was able to make things work by setting LD_LIBRARY_PATH to the stage1 directory.

$ build/x86_64-unknown-linux-gnu/stage0-tools-bin/miri --version
build/x86_64-unknown-linux-gnu/stage0-tools-bin/miri: error while loading shared libraries: librustc_driver-110e2444bfbc1fba.so: cannot open shared object file: No such file or directory

$ export LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage1/lib/
$ build/x86_64-unknown-linux-gnu/stage0-tools-bin/miri --version
rustc 1.51.0-dev

[RalfJung]

The error is about libLLVM-11-rust-1.51.0-nightly.so though, not rustc_driver or std.

I think x.py already sets LD_LIBRARY_PATH.