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.

Sign up for GitHub

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

Jump to bottom

cross run contains rustup output on stdout #1645

Open
4 of 11 tasks
arnodb opened this issue Mar 13, 2025 · 6 comments · May be fixed by #1647
Open
4 of 11 tasks

cross run contains rustup output on stdout #1645

arnodb opened this issue Mar 13, 2025 · 6 comments · May be fixed by #1647

Comments

@arnodb
Copy link

arnodb commented Mar 13, 2025

Checklist

Describe your issue

Hi, first of all thank you, cross is extremely easy to use to cross-compile rust projects.

Since the rustup 1.28.0 upgrade, I cannot use cross run ... > some_file without getting some rustup output like this at the beginning:


  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.85.0 (4d91de4e4 2025-02-17)

This is not a cross issue strictly speaking but the thing is cross run now has a different behaviour compared to cargo run. I didn't find a way to disable rustup output so I am now wondering if cross could have a workaround.

Even -q removes everything but the annoying rustup output :).

If I find no workaround then my only way to go is to change my program to take an argument (file name) and make it write to a file instead of stdout. I may implement it anyway in order to secure my builds but I wanted to let you know there is a potentially very annoying change in rustup.

If you need an occurrence of the issue, one is there: https://github.com/arnodb/truc/actions/runs/13843525751/job/38736552032#step:6:131.

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

i686-unknown-linux-gnu

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

0.2.5

Example

No response

Additional information / notes

No response
@Emilgardis
Copy link
Member

Does it do the same on the main branch? cargo install cross --git https://github.com/cross-rs/cross/

@arnodb
Copy link
Author

arnodb commented Mar 14, 2025

Good question, and the answer is yes:

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

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.85.0 (4d91de4e4 2025-02-17)

info: checking for self-update
[cross] note: Falling back to `cargo` on the host.
cargo 1.85.0 (d73d2caf9 2024-12-31)

@Emilgardis
Copy link
Member

Im not able to connect to my computer right now and dont have my laptop, could you show me the output when you set CROSS_DEBUG=1 to env?

@Emilgardis
Copy link
Member

Oh yeah, could this be rust-lang/rustup#4221 ?

Use rustup 1.28.1 and it should work as it should

@davidhewitt davidhewitt mentioned this issue Mar 14, 2025
Closed
@arnodb
Copy link
Author

arnodb commented Mar 15, 2025

Sorry for the delay...

Im not able to connect to my computer right now and dont have my laptop, could you show me the output when you set CROSS_DEBUG=1 to env?

$ CROSS_DEBUG=1 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 (ecade534c 2025-03-14)

info: checking for self-update
[cross] note: [src/bin/cross.rs:27] Falling back to `cargo` on the host.
cargo 1.87.0-nightly (ab1463d63 2025-03-08)

Side note: cross actually performs a full rustup update (even with --version).

Use rustup 1.28.1 and it should work as it should

Sorry, but no, I was already up-to-date.

$ rustup --version
rustup 1.28.1 (f9edccde0 2025-03-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.87.0-nightly (249cb8431 2025-03-12)`

@Emilgardis
Copy link
Member

ok, I'm unable to replicate this on my mac, but I think I see the issue now.

The only place where this could come from would be here I think. that code is ran depending on the output of

cross/src/rustup.rs

Lines 87 to 99 in 36c0d78

let out = rustup_command(msg_info, true)
.args(["toolchain", "list"])
.run_and_get_stdout(msg_info)?;
Ok(out
.lines()
.map(|l| {
l.replace(" (default)", "")
.replace(" (override)", "")
.trim()
.to_owned()
})
.collect())

I see that when I run rustup toolchain list, there's a new status called active available, we don't correctly handle that. This change is from rust-lang/rustup#3225

The fix then would be either removing the string from

cross/src/rustup.rs

Lines 94 to 96 in 36c0d78

l.replace(" (default)", "")
.replace(" (override)", "")
.trim()
, use rustup -q toolchain list or not match the toolchain name exactly. I think I prefer using -q, should be backwards compatible too.

@Emilgardis Emilgardis linked a pull request Mar 15, 2025 that will close this issue
Open
@michaelsproul michaelsproul mentioned this issue Mar 20, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

use -q when gathering the installed toolchains cross-rs/cross
2 participants
@Emilgardis @arnodb