Auto merge of #137036 - jieyouxu:drivers-license, r=Kobzol
Include version number of libs being built in cargo lib metadata (esp. `librustc_driver*.so`) Previously, on a non-stable channel, it's possible for two builds from different versioned sources (e.g. 1.84.0 vs 1.84.1) to produce a `librustc_driver*.so` with the same filename hashes. This causes problems with side-by-side installs wrt. linker search paths because 1.84.1 rustc bin and 1.84.0 rustc bin may try to link to the "same" `librustc_driver*.so` (same filename hash) but fail because the contents of the so is actually different. We try to mitigate this by including the version number of artifacts being built via `__CARGO_DEFAULT_LIB_METADATA` (kind of an ugly hack, but I don't think cargo has a way for us to tell cargo to use a package version override). Fixes #136701 (mitigates, really). ### Testing Tested manually[^host] by: ```bash $ cat src/version 1.86.0 $ ./x build library # w/ compiler profile, (non-stable) dev channel $ lddtree build/host/stage1/bin/rustc rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2) librustc_driver-ea1b1b2291881cc4.so => build/host/stage1/bin/../lib/librustc_driver-ea1b1b2291881cc4.so [...] ``` and observing that changing `src/version` to bump a point release causes `librustc_driver*.so` to have a different hash while sources are unmodified otherwise. ```bash $ cat src/version 1.86.1 $ ./x build library # w/ compiler profile, (non-stable) dev channel $ lddtree build/host/stage1/bin/rustc rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2) librustc_driver-746badadbcb74721.so => build/host/stage1/bin/../lib/librustc_driver-746badadbcb74721.so [...] ``` cc `@clan` `@demize` could you check that if you backport this change against 1.84.{0,1} as reported in #136701, that the produced `rustc` binary works, under the context of the Gentoo build system setup? [^host]: on a `x86_64-unknown-linux-gnu` host, no cross
This commit is contained in:
bors
commit
0d3b748975