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

cargo 0.26 outputs misleading error message when RUSTFLAGS works for stage0 but not stage1+ #50910

Closed
infinity0 opened this issue May 20, 2018 · 6 comments
Labels
T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@infinity0
Copy link
Contributor

Building with Debian patches, the error is:

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.


config.toml:

[build]
submodules = false
vendor = true
locked-deps = false
verbose = 2

rustc = "/usr/bin/rustc"
cargo = "/usr/bin/cargo"

build = "x86_64-unknown-linux-gnu"
host = ["x86_64-unknown-linux-gnu"]
target = ["x86_64-unknown-linux-gnu"]

docs = true

[install]
prefix = "/usr"

[target.x86_64-unknown-linux-gnu]
llvm-config = "/usr/lib/llvm-6.0/bin/llvm-config"

[llvm]
link-shared = true

[rust]
use-jemalloc = false
optimize = true
dist-src = false

channel = "stable"

debuginfo = true
debuginfo-lines = true
debuginfo-only-std = false
rpath = false
@infinity0 infinity0 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" May 20, 2018
@infinity0
Copy link
Contributor Author

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
Copy link
Member

If I'm interpreting correctly, RUSTFLAGS_NOT_STAGE_0 and RUSTFLAGS_STAGE_0 should work for you -- presuming you need these set during bootstrap.

@kennytm kennytm added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) C-bug Category: This is a bug. and removed C-bug Category: This is a bug. labels May 20, 2018
@infinity0
Copy link
Contributor Author

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.

@infinity0 infinity0 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+ May 20, 2018
@Mark-Simulacrum
Copy link
Member

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
Copy link
Member

Sure yeah, seems like Cargo could do a better job with the error message here

@Mark-Simulacrum
Copy link
Member

I'm going to close this in favor of refiling on Cargo if you're interested in pursuing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

No branches or pull requests

4 participants