Do not copy libstd dynamic library to sysroot

[Kobzol]

Since #122362, rustc links statically to libstd.[so|dll]. Which means that the libstd.[so|dll] file no longer has to be in the rustc sysroot. However, we are currently still shipping this file, in every new release of Rust, for no reason, it's just wasted bytes.

This PR removes the dynamic library file from the built sysroot.

However, it is not yet performed on Windows, because stage0 incremental tests start failing there (see description of the issue here).

This is an extended version of #128986.
CC @Zoxc

[rustbot]

r? @albertlarsan68

rustbot has assigned @albertlarsan68.
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

[Zoxc]

Why is this changed needed? Was it linking to the compiler's std copy before? If so, why?

[Kobzol]

The test was buggy. It compiled a Rust binary that dynamically linked to libstd.so. Then it moved the binary around, which should have broken it. However, the binary somehow linked to the compiler's std copy instead (!), so it worked by accident.

[lqd]

Since UI tests are built with -Cprefer-dynamic did they all (modulo no-prefer-dynamic) dynamically link to the compiler's std?

[Kobzol]

I don't think so, no other tests broke. It was probably just caused by the fact that this binary was moved around, lost its link to the target library and then somehow got dynamically linked to the compiler one instead.

EDIT: or, in theory, all tests could have linked to the compiler's std before, and now they link to target instead, that's a second explanation. But that would mean that all cross-compiled tests would be failing before, right?

[klensy]

Since #122362, rustc links statically to libstd.[so|dll]

Well, for CI one (x86_64-pc-windows-msvc) - yes, but my locally build copy for some reason links dynamically (messed up config.toml, probably?)

Ah, so, this is stage dependent.

[onur-ozkan]

You can r=me if you want.

[Kobzol]

As usually with these kinds of changes, it's hard to predict all the repercussions that this can have. Let's see if full CI passes, and if yes, if someone starts to complain.

@bors r=onur-ozkan rollup=never

[bors]

📌 Commit f59c8ff has been approved by onur-ozkan

It is now in the queue for this repository.

[bors]

⌛ Testing commit f59c8ff with merge e561499...

[bors]

☀️ Test successful - checks-actions
Approved by: onur-ozkan
Pushing e561499 to master...

[rust-timer]

Finished benchmarking commit (e561499): 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 (primary 1.9%, secondary 0.5%)

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)	1.9%	[1.4%, 2.4%]	2
Regressions ❌ (secondary)	3.3%	[3.3%, 3.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	1.9%	[1.4%, 2.4%]	2

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: 773.78s -> 773.813s (0.00%)
Artifact size: 342.21 MiB -> 329.46 MiB (-3.73%)