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

Output collision when using build-std and cc as build-dependency #7859

Closed
tmiasko opened this issue Feb 3, 2020 · 2 comments · Fixed by #7860
Closed

Output collision when using build-std and cc as build-dependency #7859

tmiasko opened this issue Feb 3, 2020 · 2 comments · Fixed by #7860
Labels
C-bug Category: bug Z-build-std Nightly: build-std

Comments

@tmiasko
Copy link
Contributor

tmiasko commented Feb 3, 2020

Problem

When using -Zbuild-std there is output collision between build dependencies that are common to the given project and standard library itself.

Steps

One minimal reproducer would be a project with a following Cargo.toml:

[package]
name = "a"
version = "0.1.0"
edition = "2018"
build = "build.rs"

[build-dependencies]
cc = "1.0"

And a build.rs:

extern crate cc;

fn main() {}

During build cargo warns about output collision:

$ cargo -Zbuild-std build --target x86_64-unknown-linux-gnu
warning: output filename collision.
The lib target `cc` in package `cc v1.0.50` has the same output filename as the lib target `cc` in package `cc v1.0.50`.
Colliding filename is: /.../target/debug/deps/libcc-737974c580f2da8c.rlib
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `cc` in package `cc v1.0.50` has the same output filename as the lib target `cc` in package `cc v1.0.50`.
Colliding filename is: /.../target/debug/deps/libcc-737974c580f2da8c.rmeta
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
...

When building with multiple parallel jobs the conflicts do happen and result in failures observable in a variety of ways:

  • SIGBUS: access to undefined memory
  • error: failed to build archive: No such file or directory
  • error: linking with cc failed: exit code: 1

and potentially more informative:

error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
 --> build.rs:1:1
  |
1 | extern crate cc;
  | ^^^^^^^^^^^^^^^^
  |
  = note: for more information, see https://github.com/rust-lang/rust/issues/27812
  = help: add `#![feature(rustc_private)]` to the crate attributes to enable

Notes

cargo 1.42.0-nightly (9d32b7b01 2020-01-26)

@tmiasko tmiasko added the C-bug Category: bug label Feb 3, 2020
@ehuss
Copy link
Contributor

ehuss commented Feb 3, 2020

Thanks for the report, posted a fix at #7860.

@ehuss ehuss added the Z-build-std Nightly: build-std label Feb 3, 2020
@bors bors closed this as completed in acf88cc Feb 4, 2020
@aeubanks
Copy link

aeubanks commented Aug 1, 2024

we're seeing this same issue pop up again in #14253, perhaps need more hashing of target/host?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug Z-build-std Nightly: build-std
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants