android standard libraries built in an incompatible way for use with stable rust builds

[froydnj]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1220307, I attempted to use a custom-built Rust (hosted on x86-64 Linux, if that makes a difference), built from the 1.6.0 stable branch, with the ARM Android standard libraries available from static.rust-lang.org. I received an error message about incompatible versions. But AFAICT, the Android standard libraries and the Rust I was using were built from the same revision (c30b771), so they ought to have been compatible...?

@alexcrichton said

Oh hm it looks like it's actually just doing a string comparison of the CFG_VERSION values at build-time. This I think includes the version information like 1.6.0 vs nightly. That means that if the android library is configured as built from a nightly compiler at a specific revision it's incompatible with a stable compiler at the same revision (as the version numbers are different). That... may be a bug in our compiler!

It's possible I'm mistaken about how things are supposed to work; filing this as a place to discuss.

[alexcrichton]

I believe this is because the custom-built Rust probably didn't say --channel=stable, so the version is subtly different than the stable branch (e.g. rust 1.6.0 <hash> vs rust 1.6.0-nightly <hash>)

cc @arielb1, the currently checked string originates from CFG_VERSION, but was there any particular reason to choose this over, say, the CFG_VER_HASH (e.g. the git commit)? I think that if we only check git commits it'll suffice for "these should link together" and should also prevent a situation like this.

[Mark-Simulacrum]

Do we want to make the change suggested above and check the CFG_VER_HASH instead of CFG_VERSION? If so, this seems like an E-easy issue; @alexcrichton what do you think?

[alexcrichton]

Sounds reasonable!

[Mark-Simulacrum]

Closing as a duplicate of #33286. However, in trying to summarize what needs to be done I realized we don't always have a commit hash on hand (e.g., when building from the source tarballs) so the solution reached here won't quite work I think, and I noted this there.