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
cargo 0.26 outputs misleading error message when RUSTFLAGS works for stage0 but not stage1+ #50910
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
running: "/usr/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-v" "-v" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/build/rustc-FhPMub/rustc-1.26.0+dfsg1/src/libstd/Cargo.toml" "--message-format" "json"
error: output of --print=file-names has changed in the compiler, cannot parse
command did not execute successfully: "/usr/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-v" "-v" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/build/rustc-FhPMub/rustc-1.26.0+dfsg1/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
For config.toml see the bottom of this post.
The error goes away if I build with a cleanly-unpacked upstream tarball, with this trivial patch applied, i.e LLVM is still being linked dynamically to the system one, and we're using the system rustc/cargo as stage0 bootstrap.
The error reproduces when I build with all of the Debian-specific patches and flags, but we're not doing anything particularly crazy on top of what I just described. I don't know how to debug this, cargo is not giving me any more information on what it's expecting to see from rustc nor what's wrong.
changed the title [-]rustc 1.26.0 Debian fails to build with cargo 0.26.0[/-][+]rustc 1.26.0 Debian fails to build with cargo 0.26.0, "output of --print=file-names has changed"[/+]on May 20, 2018
In Debian we've been passing -Zremap-path-prefix-{from,to}. I think this was caused by #48359 which renamed this flag and landed in 1.26.0, and we're still passing the old flag in RUSTFLAGS. I'll see if I can figure out a way to pass the old flag to the stage0 compiler and the new flag after that, otherwise I'll just ditch it temporarily until 1.27.0 when both stage0 and stage1 will recognize the same flags.
Thanks, these flags worked. Not sure why the more appropriate error message here was not triggered. Probably a cargo issue, let me know if I should move it.
changed the title [-]rustc 1.26.0 Debian fails to build with cargo 0.26.0, "output of --print=file-names has changed"[/-][+]cargo 0.26 outputs misleading error message when RUSTFLAGS works for stage0 but not stage1+[/+]on May 20, 2018
Activity
[-]rustc 1.26.0 Debian fails to build with cargo 0.26.0[/-][+]rustc 1.26.0 Debian fails to build with cargo 0.26.0, "output of --print=file-names has changed"[/+]infinity0 commentedon May 20, 2018
In Debian we've been passing
-Zremap-path-prefix-{from,to}. I think this was caused by #48359 which renamed this flag and landed in 1.26.0, and we're still passing the old flag in RUSTFLAGS. I'll see if I can figure out a way to pass the old flag to the stage0 compiler and the new flag after that, otherwise I'll just ditch it temporarily until 1.27.0 when both stage0 and stage1 will recognize the same flags.Mark-Simulacrum commentedon May 20, 2018
If I'm interpreting correctly,
RUSTFLAGS_NOT_STAGE_0andRUSTFLAGS_STAGE_0should work for you -- presuming you need these set during bootstrap.infinity0 commentedon May 20, 2018
Thanks, these flags worked. Not sure why the more appropriate error message here was not triggered. Probably a cargo issue, let me know if I should move it.
[-]rustc 1.26.0 Debian fails to build with cargo 0.26.0, "output of --print=file-names has changed"[/-][+]cargo 0.26 outputs misleading error message when RUSTFLAGS works for stage0 but not stage1+[/+]Mark-Simulacrum commentedon May 20, 2018
Hm, that does seem like a Cargo issue, though it might be rustc isn't properly setting the status code in some cases.
@alexcrichton might be able to comment on whether this should be re-filed as a poor message bug on Cargo's side
alexcrichton commentedon May 21, 2018
Sure yeah, seems like Cargo could do a better job with the error message here
Mark-Simulacrum commentedon May 28, 2018
I'm going to close this in favor of refiling on Cargo if you're interested in pursuing this.