Nightly builds fail - libLLVM issue

[axos88]

Checklist

• I've looked through the issues and pull requests for similar reports

Describe your issue

#1496 seems related.

  failed to run rustc: rustc: error while loading shared libraries: libLLVM.so.19.1-rust-1.86.0-nightly: cannot open shared object file: No such file or directory

Repro:

• Generate new project
• Add rustls = { version = "*", default-features=false, features=["ring"] } as dependency
• rustup default nightly
• run cross build --target arm-unknown-linux-gnueabi

$ cross  build --target  arm-unknown-linux-gnueabi
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.87.0-nightly (43a2e9d2c 2025-03-17)

info: checking for self-update
   Compiling libc v0.2.171
error: failed to run custom build command for `libc v0.2.171`

Caused by:
  process didn't exit successfully: `/target/debug/build/libc-ae77d5e3ffd276c6/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs

  --- stderr

  thread 'main' panicked at /home/akos/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libc-0.2.171/build.rs:147:9:
  failed to run rustc: rustc: error while loading shared libraries: libLLVM.so.20.1-rust-1.87.0-nightly: cannot open shared object file: No such file or directory

  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

What target(s) are you cross-compiling for?

arm-unknown-linux-gnueabi

Which operating system is the host (e.g computer cross is on) running?

• macOS
• Windows
• Linux / BSD
• other OS (specify in description)

What architecture is the host?

• x86_64 / AMD64
• arm32
• arm64 (including Mac M1)

What container engine is cross using?

• docker
• podman
• other container engine (specify in description)

cross version

cross 0.2.5 (36c0d78 2025-03-08)

Example

[Emilgardis]

Could you try reinstalling the nightly toolchain by uninstalling and reinstalling it?

[solimike]

FWIW I had a go at the repro using the exact same version of cross and nightly toolchain and everything compiled cleanly without any errors. My host was Ubuntu 22.04.5 under WSL2.

$ cross --version
cross 0.2.5 (36c0d78 2025-03-08)
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.87.0-nightly (43a2e9d2c 2025-03-17)

info: checking for self-update
[cross] note: Falling back to `cargo` on the host.
cargo 1.87.0-nightly (6cf826701 2025-03-14)

$ cargo init hello-cross-i1650
    Creating binary (application) package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
$ cd hello-cross-i1650/

$ cargo add rustls

Edited cargo.toml to match OP's config

$ cross  build --target  arm-unknown-linux-gnueabi
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.87.0-nightly (43a2e9d2c 2025-03-17)

info: checking for self-update
Unable to find image 'ghcr.io/cross-rs/arm-unknown-linux-gnueabi:main' locally
main: Pulling from cross-rs/arm-unknown-linux-gnueabi
d9802f032d67: Pull complete
42ba323b8bcc: Pull complete
98d0111438a7: Pull complete
8255e7d346d7: Pull complete
e7bcf4121f38: Pull complete
6c68d0b68811: Pull complete
546589b49558: Pull complete
3b8ab7a401d8: Pull complete
193db9c54266: Pull complete
4c299e8f7700: Pull complete
61b1aceaf6d3: Pull complete
dad60550f61f: Pull complete
0af4f8d4556c: Pull complete
2de6751d7a52: Pull complete
ef18c78fd6d7: Pull complete
Digest: sha256:c6c9f47f82ef0df927863dd1500d8dd43e9639b59e3459a198071a1ba263ee4f
Status: Downloaded newer image for ghcr.io/cross-rs/arm-unknown-linux-gnueabi:main
   Compiling shlex v1.3.0
   Compiling libc v0.2.171
   Compiling cfg-if v1.0.0
   Compiling untrusted v0.9.0
   Compiling rustls-pki-types v1.11.0
   Compiling rustls v0.23.25
   Compiling subtle v2.6.1
   Compiling cc v1.2.16
   Compiling once_cell v1.21.1
   Compiling zeroize v1.8.1
   Compiling getrandom v0.2.15
   Compiling ring v0.17.14
   Compiling rustls-webpki v0.103.0
   Compiling hello-cross-i1650 v0.1.0 (/home/******/git-repos/hello-cross-i1650)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 7.05s
$ cross  run --target  arm-unknown-linux-gnueabi
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.87.0-nightly (43a2e9d2c 2025-03-17)

info: checking for self-update
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s
     Running `/qemu-runner arm /target/arm-unknown-linux-gnueabi/debug/hello-cross-i1650`
Hello, world!

Hope that's a useful data point!

[axos88]

That's weird. I'll try to repro again later. I had the same issue locally and in a github action as well!

[axos88]

Oh yeah, your rust is too new. Please try nightly-2025-01-12

[axos88]

For some odd reason i get backward incompatibilities with my code after 1.87, so news to use 1.86 until i figure out how to solve it. Cross works for nightly latest, but not with that version

[solimike]

Not for me - works fine with nightly-2025-01-12:

$ cross  build --target  arm-unknown-linux-gnueabi
info: syncing channel updates for 'nightly-2025-01-12-x86_64-unknown-linux-gnu'

  nightly-2025-01-12-x86_64-unknown-linux-gnu unchanged - rustc 1.86.0-nightly (eb54a5083 2025-01-11)

info: checking for self-update
   Compiling shlex v1.3.0
   Compiling libc v0.2.171
   Compiling cfg-if v1.0.0
   Compiling untrusted v0.9.0
   Compiling rustls-pki-types v1.11.0
   Compiling rustls v0.23.25
   Compiling zeroize v1.8.1
   Compiling once_cell v1.21.1
   Compiling cc v1.2.16
   Compiling subtle v2.6.1
   Compiling getrandom v0.2.15
   Compiling ring v0.17.14
   Compiling rustls-webpki v0.103.0
   Compiling hello-cross-i1650 v0.1.0 (/home/XXXXX/git-repos/hello-cross-i1650)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 5.98s

I also note that your original report at the top of this issue seems to have been from 1.87.0-nightly (43a2e9d2c 2025-03-17), wasn't it? Perhaps some other variable in your environment is behind the failing/non-failing behaviour?