Include version number of libs being built in cargo lib metadata (esp. librustc_driver*.so)

[jieyouxu]

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¹ by:

$ 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.

$ 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?

Footnotes

1. on a x86_64-unknown-linux-gnu host, no cross ↩

[rustbot]

r? @Kobzol

rustbot has assigned @Kobzol.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

cc @jyn514 @bjorn3 I would appreciate if you could double-check if this change is something that we can do. I'm not 100% sure of the implications or unintended side-effects of including the src/version info in cargo lib metadata here.

[jyn514]

this looks reasonable to me. The worst that could happen, other than just not working, is that cargo would rebuild more often than necessary, or link in multiple versions of the same crate with different hashes.

i would only expect that to happen though if someone modifies src/version while bootstrap is running, which, why? so i don't think this is very risky.

[jyn514]

ideally we would pass the version number to cargo somehow. it's weird to try and manage cargo's metadata for it. but if that's hard this is fine as a workaround.

(there's been an ongoing pattern where there's an impedance mismatch between what bootstrap is doing and what cargo is doing...sometimes I wish we had our own build system instead of just wrapping cargo.)

[jieyouxu]

i would only expect that to happen though if someone modifies src/version while bootstrap is running, which, why? so i don't think this is very risky.

Yes, that'll rebuild, but also, don't do that

[jieyouxu]

ideally we would pass the version number to cargo somehow. it's weird to try and manage cargo's metadata for it. but if that's hard this is fine as a workaround.

Yeah unfortunately I don't know of a way to somehow override the crate version number.

[demize]

Applied the patch through portage, installed 1.84.0 again and rebuilt 1.84.1, all good on my end:

demize@yveltal ~ $ /usr/bin/rustc-1.84.0 -vV
rustc 1.84.0-nightly (9fc6b4312 2025-01-07) (gentoo)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.7
demize@yveltal ~ $ /usr/bin/rustc-1.84.1 -vV
rustc 1.84.1-nightly (e71f9a9a9 2025-01-27) (gentoo)
binary: rustc
commit-hash: e71f9a9a98b0faf423844bf0ba7438f29dc27d58
commit-date: 2025-01-27
host: x86_64-unknown-linux-gnu
release: 1.84.1-nightly
LLVM version: 19.1.7
demize@yveltal ~ $ lddtree /usr/bin/rustc-1.84.{0,1}
rustc-1.84.0 => /usr/bin/rustc-1.84.0 (interpreter => /lib64/ld-linux-x86-64.so.2)
    librustc_driver-ea0e1b0c5d10469b.so => not found
    libc.so.6 => /usr/lib64/libc.so.6
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
rustc-1.84.1 => /usr/bin/rustc-1.84.1 (interpreter => /lib64/ld-linux-x86-64.so.2)
    librustc_driver-6f5156ee640647f4.so => not found
    libc.so.6 => /usr/lib64/libc.so.6
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2

[jieyouxu]

FWIW I'm not super happy with this comment, lmw if there's a better wording/explanation for it.

[jyn514]

this is a problem regardless of the channel. it just happens to not trigger on stable because cargo uses different heuristics per-channel for what to include in the metadata hash.