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

[E0514] error message not clear #30363

Closed
MagaTailor opened this issue Dec 13, 2015 · 14 comments
Closed

[E0514] error message not clear #30363

MagaTailor opened this issue Dec 13, 2015 · 14 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@MagaTailor
Copy link

I was trying to cross-compile something, and even though, the identically named down to the hash (compatible?), std crate for the cross arch had come from the same minor version (rustc 1.6.0-dev) I still got the error:

 hello.rs:1:1: 1:1 error: the crate `std` has been compiled with rustc 1.6.0-dev, which is incompatible with this version of rustc [E0514]

What is required for the crates to be compatible then? The exact commit hash of the rust compilers as well?

If so, this issue could be about something else too - building from a full source snapshot (instead of git clones) doesn't put the hash info into the binary.

@sfackler
Copy link
Member

The compilers must have been built from the same commit.

@MagaTailor
Copy link
Author

Strange that it's not printing the hash if it's still able to compare against it.

@ticki
Copy link
Contributor

ticki commented Dec 14, 2015

Try to run cargo clean

@MagaTailor
Copy link
Author

Fresh from the reddit thread, eh?
It's not that issue.

EDIT:
https://www.reddit.com/r/rust/comments/3wic4c/error_the_crate_regex_has_been_compiled_with_an/

@ticki
Copy link
Contributor

ticki commented Dec 14, 2015

Reddit thread?

@arielb1
Copy link
Contributor

arielb1 commented Dec 14, 2015

What compilers were you using?

@MagaTailor
Copy link
Author

Those were 1.6 nightlies for armhf (from rustbuild) and i686 (mine) architectures roughly from the same day - hence the matching crate names.

@arielb1
Copy link
Contributor

arielb1 commented Dec 14, 2015

Apparently the nightlies are built with different values of CFG_VERSION. Could @alexcrichton investigate?

@arielb1
Copy link
Contributor

arielb1 commented Dec 14, 2015

The CFG_VERSION is visible by doing strings $RLIB_FILE_CREATED_BY_RUSTC | grep "rustc 1[.]", or by rustc --version.

@alexcrichton
Copy link
Member

I guess this may depend on the string being compared, the nightly compilers have the version string ending with -nightly and from-source builds use -dev by default (configurable either way of course).

I wonder if perhaps this check should just compare commit revisions?

@MagaTailor
Copy link
Author

I can confirm I got it working in both directions using 1.5.0-dev (after building from the same snapshot on both architectures) - rustc -vV doesn't include the hash info nor build date though.

@MagaTailor
Copy link
Author

I'd like to suggest including the commit info in the full source snapshots so that it can be parsed by the build scripts and rustc -vV doesn't end up like this:

rustc 1.8.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: arm-unknown-linux-gnueabihf
release: 1.8.0-dev

@MagaTailor
Copy link
Author

The original issue has turned out to be about something else - fully compatible crates were being rejected for the sole reason CFG_VERSION was different. Otherwise, the message would have been crystal clear.

In other words, it's not possible to pick up crates from rust-lang and use them in your own compiler built from tarball source, meaning #30622 shouldn't close this.

@MagaTailor
Copy link
Author

#33286

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants