Skip to content

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

Closed

Description

@infinity0

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

Activity

  1. 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
  2. infinity0 commented on May 20, 2018

    @infinity0
    ContributorAuthor

    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.

  3. Mark-Simulacrum commented on May 20, 2018

    @Mark-Simulacrum
    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.

  4. added
    T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
    C-bugCategory: This is a bug.
    and removed
    C-bugCategory: This is a bug.
    on May 20, 2018
  5. infinity0 commented on May 20, 2018

    @infinity0
    ContributorAuthor

    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.

  6. 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
  7. Mark-Simulacrum commented on May 20, 2018

    @Mark-Simulacrum
    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

  8. alexcrichton commented on May 21, 2018

    @alexcrichton
    Member

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

  9. Mark-Simulacrum commented on May 28, 2018

    @Mark-Simulacrum
    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions