Closed ehuss closed 4 years ago
I think that we can safely ignore this. The rationale for adding this in the compiler itself was due to various sorts of build failures that cropped up in the real world and this fixed them, so if we don't have any build failures I think it's fine.
I ran a test locally to verify this. Today libstd links to libc 0.2.61
, so I ran cargo new --lib
, added:
[dependencies]
libc = "=0.2.61"
and then updated code to be
pub fn foo() -> usize {
libc::open as usize
}
A cargo +nightly build -Z build-std --target x86_64-unknown-linux-gnu
build then worked for me. Sure enough there's two liblibc-*.rlib
in the output directory.
I think we can safely ignore this until it's actually a problem, and I predict that enough has changed in the meantime that this isn't needed anyway from within Cargo. As a result I'm gonna go ahead and close this.
The metadata hash currently includes the
__CARGO_DEFAULT_LIB_METADATA
environment variable which is used for embedding the release channel in the hash. This is used by rustbuild, but the current cargo implementation does not use it. Need to consider if this is necessary.