Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error: no such subcommand: cargo #357

Closed
iostat opened this issue Dec 4, 2019 · 10 comments · Fixed by #358
Closed

error: no such subcommand: cargo #357

iostat opened this issue Dec 4, 2019 · 10 comments · Fixed by #358

Comments

@iostat
Copy link
Contributor

iostat commented Dec 4, 2019

Hi!
I'm trying to run some cross jobs in Travis using nightly. Versions are as follows:

$ cargo --version
cargo 1.41.0-nightly (750cb1482 2019-11-23)
$ cross --version
cross 0.1.16
cargo 1.41.0-nightly (750cb1482 2019-11-23)
$ rustup --version
rustup 1.20.2 (13979c968 2019-10-16)

When running a relatively simple cross build --target armv7-unknown-linux-gnueabihf, I get the following output. This behavior occurs regardless of my actual target:

$ cross build --target armv7-unknown-linux-gnueabihf
error: no such subcommand: `cargo`

Going --verbose, I get the following:

$ cross build --target armv7-unknown-linux-gnueabihf --verbose
+ "rustc" "rustc" "--print" "sysroot"
+ "rustup" "rustup" "toolchain" "list"
+ "rustup" "rustup" "target" "list" "--toolchain" "nightly-x86_64-unknown-linux-gnu"
+ "rustup" "rustup" "component" "list" "--toolchain" "nightly-x86_64-unknown-linux-gnu"
+ "cargo" "cargo" "fetch" "--manifest-path" "/home/travis/build/my/project/Cargo.toml"
+ "docker" "docker" "run" "--userns" "host" "--rm" "--user" "2000:2000" "-e" "XARGO_HOME=/xargo" "-e" "CARGO_HOME=/cargo" "-e" "CARGO_TARGET_DIR=/target" "-e" "USER=travis" "-e" "PKG_CONFIG_PATH" "-e" "PKG_CONFIG_ALLOW_CROSS" "-e" "CROSS_RUNNER=" "-v" "/home/travis/.xargo:/xargo:Z" "-v" "/home/travis/.cargo:/cargo:Z" "-v" "/cargo/bin" "-v" "/home/travis/build/my/project:/project:Z,ro" "-v" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu:/rust:Z,ro" "-v" "/home/travis/build/my/project/target:/target:Z" "-w" "/project" "-i" "-t" "my/custom-cross:armv7-unknown-linux-gnueabihf-v0.1.16" "sh" "-c" "PATH=$PATH:/rust/bin \"cargo\" \"cargo\" \"build\" \"--target\" \"armv7-unknown-linux-gnueabihf\" \"--verbose\""
error: no such subcommand: `cargo`

Note that while I am using a custom Docker image, the same behavior occurs even with the default images.

My Cross.toml is as follows:

[build.env]
passthrough = ["PKG_CONFIG_PATH", "PKG_CONFIG_ALLOW_CROSS"]

[target.armv7-unknown-linux-gnueabihf]
image = "my/custom-cross:armv7-unknown-linux-gnueabihf-v0.1.16"

[target.aarch64-unknown-linux-gnu]
image = "my/custom-cross:aarch64-unknown-linux-gnu-v0.1.16"

[target.x86_64-unknown-linux-gnu]
image = "my/custom-cross:x86_64-unknown-linux-gnu-v0.1.16"

It seems like it's adding the command its running as an additional argument to itself, at least according to the logs. Running this on my local machine (macOS Mojave 10.14.6), I don't see this "doubling" behavior. My local machine is running the same version of cross as my Travis build.

cross 0.1.16
cargo 1.41.0-nightly (750cb1482 2019-11-23)

I'm kinda stumped -- I don't see anything in the code that's immediately obvious as a bug/regression or assumption about the running environment that Travis might be violating. Any ideas?

@reitermarkus
Copy link
Member

Can you try installing cross from the master branch and see if it still behaves in the same way?

cargo install --git https://github.com/rust-embedded/cross --force

@iostat
Copy link
Contributor Author

iostat commented Dec 5, 2019

Didn't seem to help, appears to have the same exact behavior (just now with cross 0.2.0-alpha.1 instead of 0.1.16)

@Amanieu
Copy link

Amanieu commented Dec 6, 2019

This issue is blocking CI for hashbrown.

@connorworley
Copy link

Also seeing the same behavior

@reitermarkus
Copy link
Member

Could it be that Debug for Command is platform specific?

@iostat
Copy link
Contributor Author

iostat commented Dec 7, 2019 via email

@iostat
Copy link
Contributor Author

iostat commented Dec 7, 2019 via email

@iostat
Copy link
Contributor Author

iostat commented Dec 7, 2019

Which appears to have changed 19 days ago (ignoring the "run rustfmt commit"): rust-lang/rust@6dee1a5#diff-1d80df5045655b492de85da768fbcab7L135-L150

@iostat
Copy link
Contributor Author

iostat commented Dec 7, 2019

I guess the real issue here is depending on the Debug impl of Command to escape out a command into Docker arguments

@reitermarkus
Copy link
Member

Yeah, we should use something like

https://crates.io/crates/shell-escape

instead.

@bors bors bot closed this as completed in 105a4ae Dec 9, 2019
@bors bors bot closed this as completed in #358 Dec 9, 2019
BurntSushi added a commit to BurntSushi/ripgrep that referenced this issue Jan 10, 2020
Looks like the old japaric images are bunk. We update our docker image
to be based on the new rustembedded images and configure cross to use
it.

Turns out that this wasn't due to a stale docker image, but rather, a
bug in cross: cross-rs/cross#357
We work around that bug by installing the master branch of cross. Sigh.
BurntSushi added a commit to BurntSushi/ripgrep that referenced this issue Jan 10, 2020
Looks like the old japaric images are bunk. We update our docker image
to be based on the new rustembedded images and configure cross to use
it.

Turns out that this wasn't due to a stale docker image, but rather, a
bug in cross: cross-rs/cross#357
We work around that bug by installing the master branch of cross. Sigh.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants