You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Immediately Terminates with "'rustc --print target-list' failed" #526
changed the title [-]Immediately Terminates with '"rustc --print target-list" failed'[/-][+]Immediately Terminates with "'rustc --print target-list' failed"[/+]on Mar 5, 2021
Has this been resolved? I'm getting this error as well:
$ sudo cross build --target armv7-unknown-linux-gnueabihf
error: `"rustc" "--print" "target-list"` failed with exit code: Some(1)
note: run with `RUST_BACKTRACE=1` for a backtrace
This failing suggests something odd is happening with your system. Can you report the output of:
# we don't care about stdout, just the error output and exit code
$ rustc --print target-list >/dev/null
$ echo$?
This should give 0, indicating success, but something tells me on your systems it's not.
I've tried this on x86_64-unknown-linux-gnu and with the following toolchain versions:
rustc 1.52.0-nightly (8e54a2113 2021-02-13)
rustc 1.59.0 (9d1b2106e 2022-02-23)
rustc 1.61.0 (fe5b13d68 2022-05-18)
rustc 1.63.0-nightly (5435ed691 2022-06-07)
I've tried both the 0.2.1 release and cross built from main. This suggests to me it's probably not an issue in cross or the rust version but an issue in the installed rust toolchain.
tl;dr rustc --print target-list is returning a non-zero exit code, suggesting it's failed, which is causing cross to fail.
This no longer reproduces it seems. I've got verbose output information from cross v0.2.2 running with those specific toolchains, on an x86_64-unknown-linux-gnu host. This might an issue if you haven't installed some dependencies to run cargo or other Rust binaries, such as libgcc.
$ cross +1.54 --version
cross 0.2.2
Warning: using older rustc `1.54.0 (a178d0322 2021-07-26)`for the target. Current active rustc on the host is `rustc 1.61.0 (fe5b13d68 2022-05-18)`.
> Update with `rustup update --force-non-host 1.54-x86_64-unknown-linux-gnu`
Warning: Falling back to `cargo` on the host.
cargo 1.54.0 (5ae8d74b3 2021-06-22)
+ cargo metadata --format-version 1 --filter-platform armv7-unknown-linux-gnueabihf
+ rustc --print sysroot
+ rustup toolchain list
Warning: using older rustc `1.54.0 (a178d0322 2021-07-26)`for the target. Current active rustc on the host is `rustc 1.61.0 (fe5b13d68 2022-05-18)`.
> Update with `rustup update --force-non-host 1.54.0-x86_64-unknown-linux-gnu`
+ rustup target list --toolchain 1.54.0-x86_64-unknown-linux-gnu
+ rustup component list --toolchain 1.54.0-x86_64-unknown-linux-gnu
+ rustup component add rust-src --toolchain 1.54.0-x86_64-unknown-linux-gnu
info: downloading component 'rust-src'
info: installing component 'rust-src'
+ /usr/bin/docker
+ /usr/bin/docker run --userns host -e 'PKG_CONFIG_ALLOW_CROSS=1' -e 'XARGO_HOME=/xargo' -e 'CARGO_HOME=/cargo' -e 'CARGO_TARGET_DIR=/target' -e 'CROSS_RUNNER=' -e 'USER=ahuszagh' --rm --user 1000:1000 -v /home/ahuszagh/.xargo:/xargo:Z -v /home/ahuszagh/.cargo:/cargo:Z -v /cargo/bin -v /home/ahuszagh/Desktop/cross/rust-c-hello-world:/project:Z -v /home/ahuszagh/.rustup/toolchains/1.54.0-x86_64-unknown-linux-gnu:/rust:Z,ro -v /home/ahuszagh/Desktop/cross/rust-c-hello-world/target:/target:Z -w /project -i ghcr.io/cross-rs/armv7-unknown-linux-gnueabihf:main sh -c 'PATH=$PATH:/rust/bin cargo run --target armv7-unknown-linux-gnueabihf -vv'
Fresh cc v1.0.73
Fresh hellopp v0.1.0 (/project)
Finished dev [unoptimized + debuginfo] target(s) in 0.14s
Running `/linux-runner armv7 /target/armv7-unknown-linux-gnueabihf/debug/hellopp`
Hello, world!
Okay, it works fine without sudo I guess. Something with the build system is running the build as the wrong user. Weird error message in this case, but I guess that's the issue.
Update: The CI is indeed running as the correct user, confirmed via "echo "$USER" before cross build.
However, now, when I run as my own user, I get:
cross build --release --target x86_64-unknown-linux-gnu
Compiling libc v0.2.139
Compiling cfg-if v1.0.0
Compiling once_cell v1.17.1
error: failed to run custom build command for `libc v0.2.139`
Caused by:
process didn't exit successfully: `/target/release/build/libc-ba75df37419bc002/build-script-build` (exit status: 1)
--- stderr
/target/release/build/libc-ba75df37419bc002/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /target/release/build/libc-ba75df37419bc002/build-script-build)
/target/release/build/libc-ba75df37419bc002/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /target/release/build/libc-ba75df37419bc002/build-script-build)
/target/release/build/libc-ba75df37419bc002/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /target/release/build/libc-ba75df37419bc002/build-script-build)
warning: build failed, waiting for other jobs to finish...
On Debian Testing.
If I omit --release, then it works (I get sqlx compilation errors probably due to not passing env variable into cross/docker, which I can always fix):
Activity
[-]Immediately Terminates with '"rustc --print target-list" failed'[/-][+]Immediately Terminates with "'rustc --print target-list' failed"[/+]clarfonthey commentedon May 6, 2021
Also getting this error. Not really sure where to go from here.
uber-alles-code commentedon Jun 6, 2021
Having the same issue...
ondrowan commentedon Aug 5, 2021
The same thing started to happen with Rust 1.54.0 and target
armv7-unknown-linux-gnueabihf. It works with 1.52.1 and 1.53.0.dbischof90 commentedon Mar 24, 2022
Has this been resolved? I'm getting this error as well:
Emilgardis commentedon Mar 24, 2022
@dbischof90 can you please add
-vvto the arguments for debug output? Also what version of cross are tou using?dbischof90 commentedon Mar 24, 2022
Rowing back - I think I solved at least my case.
I had to add my user to the
dockerusergroup and run it without sudo, that seemed to make the difference!EDIT: my
crosssetup isand I run on Arch. But that seems to be unrelated here. With
-vvI see thatso it needs my username as input which might not be accessible if called through
sudo. Is that possible?Alexhuszagh commentedon Jun 15, 2022
This command should be running on the host, and therefore shouldn't be affected by whether or not Docker is invoked or not.
cross/src/lib.rs
Line 279 in d90b016
This failing suggests something odd is happening with your system. Can you report the output of:
This should give
0, indicating success, but something tells me on your systems it's not.I've tried this on
x86_64-unknown-linux-gnuand with the following toolchain versions:I've tried both the 0.2.1 release and cross built from main. This suggests to me it's probably not an issue in cross or the rust version but an issue in the installed rust toolchain.
tl;dr
rustc --print target-listis returning a non-zero exit code, suggesting it's failed, which is causingcrossto fail.Alexhuszagh commentedon Jul 2, 2022
This no longer reproduces it seems. I've got verbose output information from cross v0.2.2 running with those specific toolchains, on an
x86_64-unknown-linux-gnuhost. This might an issue if you haven't installed some dependencies to run cargo or other Rust binaries, such aslibgcc.Nor does it fail on the nightly compiler:
If there are still issues, I'll re-open this.
winrid commentedon Mar 29, 2023
So, I'm running into this.
Would print
0.But the build would fail on getting the target list:
My user is part of the docker group:
Still debugging.
winrid commentedon Mar 29, 2023
Okay, it works fine without sudo I guess. Something with the build system is running the build as the wrong user. Weird error message in this case, but I guess that's the issue.
winrid commentedon Mar 29, 2023
Update: The CI is indeed running as the correct user, confirmed via "echo "$USER" before
cross build.However, now, when I run as my own user, I get:
On Debian Testing.
If I omit
--release, then it works (I get sqlx compilation errors probably due to not passing env variable into cross/docker, which I can always fix):Info:
Wonder if it's due to a somewhat old version of Debian... will try upgrading I guess since 10 is EOL. Build servers tend to live too long. :)
Emilgardis commentedon Mar 29, 2023
The issue you're seeing is #724
Don't use sudo with cross
Use "sudo" to run tests on github workflows.
Use "sudo" to run tests on github workflows.
Use "sudo" to run tests on github workflows.
Use "sudo" to run tests on github workflows.
Use "sudo" to run tests on github workflows.
Fix the mount tests (#2269)