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

[Kobzol]

In case this causes problems down the line, let's mark it as rollup=never.

@bors r+ rollup=never

[bors]

📌 Commit 4f87987 has been approved by Kobzol

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4f87987 with merge 2af87ea...

[bors]

☀️ Test successful - checks-actions
Approved by: Kobzol
Pushing 2af87ea to master...

[rust-timer]

Finished benchmarking commit (2af87ea): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (secondary 2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 771.091s -> 771.836s (0.10%)
Artifact size: 361.99 MiB -> 361.95 MiB (-0.01%)