Stop linking rs{begin,end} objects on x86_64-*-windows-gnu #146758
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-author
|
@bors try jobs=x86_64-unknown-linux-gnu,x86_64-pc-windows-gnu,i686-pc-windows-gnu |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Sep 19, 2025
Stop linking rs{begin,end} on x86_64-*-windows-gnu
try-job: x86_64-unknown-linux-gnu
try-job: x86_64-pc-windows-gnu
try-job: i686-pc-windows-gnu
|
💔 Test for 39b94f2 failed: CI. Failed job:
|
|
@bors try jobs=dist-x86_64-linux,dist-x86_64-mingw,dist-i686-mingw |
|
❌ Encountered an error while executing command |
This comment has been minimized.
This comment has been minimized.
|
@bors try jobs=dist-x86_64-linux,dist-x86_64-mingw,dist-i686-mingw |
rust-bors bot
added a commit
that referenced
this pull request
Sep 19, 2025
Stop linking rs{begin,end} on x86_64-*-windows-gnu
try-job: dist-x86_64-linux
try-job: dist-x86_64-mingw
try-job: dist-i686-mingw
This comment has been minimized.
This comment has been minimized.
|
If this works we can also stop building them inside bootstrap, right? rust/src/bootstrap/src/core/build_steps/compile.rs Lines 898 to 900 in 2f4dfc7 |
Surely, I decided to keep them for now (at least for this try build) to discuss it first. Deleting them might require an MCP because downstream crates might depend on them. Fast GitHub search shows that at least xargo uses them: https://github.com/japaric/xargo/blob/68e0ca57cd90837fe02f262f074182f9cfeb6227/src/sysroot.rs#L62
Whatever you prefer, I can include it here, or you can create a follow-up PR. |
I will do it in a follow up PR. |
Details
Details
Details
DetailsThis basically confirms that for x86_64-pc-windows-gnu, Rust specific objects are not linked any more and Also in case somebody doubts whether these files were really unnecessary on x86_64, here is the proof: Details |
mati865
changed the title
Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced. Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1. The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`.
mati865
force-pushed
the
amd64_mingw_no_rs_objects
branch
from
3b391e3 to
7eea65f
Compare
rustbot
added
the
T-bootstrap
|
Started the discussion at #t-compiler > Removing `rs{begin,end}.o` objects for x86_64-pc-windows-gnu |
|
I believe separating out the question of whether or not to ship the artifacts from whether or not to link the artifacts is correct, as it basically is a T-compiler decision how we use them and a T-release decision whether we ship them. ( We work closely together but there's still, yanno, process. ) |
petrochenkov
added
S-waiting-on-review
|
These commits modify compiler targets. |
I don't think this change needs any additional process if we are still shipping the objects. |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 26, 2025
… r=petrochenkov
Stop linking rs{begin,end} objects on x86_64-*-windows-gnu
Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced.
Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1.
The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`.
Fixes rust-lang#146739
This was referenced Sep 26, 2025
bors
added a commit
that referenced
this pull request
Sep 26, 2025
Rollup of 10 pull requests Successful merges: - #145113 (resolve: Do not finalize shadowed bindings) - #146523 (Demote both armebv7r-none-* targets.) - #146704 (port `#[debugger_visualizer]` to the new attribute system) - #146758 (Stop linking rs{begin,end} objects on x86_64-*-windows-gnu) - #146778 (Use standard attribute logic for allocator shim) - #146849 (Reduce some uses of `LegacyBang`) - #147016 (fix doc comments to be more standard) - #147027 (Add new `tyalias` intra-doc link disambiguator) - #147031 (mbe: Simplify check_redundant_vis_repetition) - #147058 (Ignore more failing ui tests for GCC backend) Failed merges: - #147046 (Rename `rust.use-lld` to `rust.bootstrap-override-lld`) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
that referenced
this pull request
Sep 27, 2025
Rollup of 10 pull requests Successful merges: - #145113 (resolve: Do not finalize shadowed bindings) - #146523 (Demote both armebv7r-none-* targets.) - #146704 (port `#[debugger_visualizer]` to the new attribute system) - #146758 (Stop linking rs{begin,end} objects on x86_64-*-windows-gnu) - #146778 (Use standard attribute logic for allocator shim) - #146849 (Reduce some uses of `LegacyBang`) - #147016 (fix doc comments to be more standard) - #147027 (Add new `tyalias` intra-doc link disambiguator) - #147031 (mbe: Simplify check_redundant_vis_repetition) - #147058 (Ignore more failing ui tests for GCC backend) Failed merges: - #147046 (Rename `rust.use-lld` to `rust.bootstrap-override-lld`) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Sep 27, 2025
Rollup merge of #146758 - mati865:amd64_mingw_no_rs_objects, r=petrochenkov Stop linking rs{begin,end} objects on x86_64-*-windows-gnu Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced. Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1. The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`. Fixes #146739
github-actions bot
pushed a commit
to rust-lang/rust-analyzer
that referenced
this pull request
Sep 29, 2025
Rollup of 10 pull requests Successful merges: - rust-lang/rust#145113 (resolve: Do not finalize shadowed bindings) - rust-lang/rust#146523 (Demote both armebv7r-none-* targets.) - rust-lang/rust#146704 (port `#[debugger_visualizer]` to the new attribute system) - rust-lang/rust#146758 (Stop linking rs{begin,end} objects on x86_64-*-windows-gnu) - rust-lang/rust#146778 (Use standard attribute logic for allocator shim) - rust-lang/rust#146849 (Reduce some uses of `LegacyBang`) - rust-lang/rust#147016 (fix doc comments to be more standard) - rust-lang/rust#147027 (Add new `tyalias` intra-doc link disambiguator) - rust-lang/rust#147031 (mbe: Simplify check_redundant_vis_repetition) - rust-lang/rust#147058 (Ignore more failing ui tests for GCC backend) Failed merges: - rust-lang/rust#147046 (Rename `rust.use-lld` to `rust.bootstrap-override-lld`) r? `@ghost` `@rustbot` modify labels: rollup
|
Updated cg_clif to stop building these object files in rust-lang/rustc_codegen_cranelift@ed6fbc2. |
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Oct 18, 2025
Rollup of 10 pull requests Successful merges: - rust-lang/rust#145113 (resolve: Do not finalize shadowed bindings) - rust-lang/rust#146523 (Demote both armebv7r-none-* targets.) - rust-lang/rust#146704 (port `#[debugger_visualizer]` to the new attribute system) - rust-lang/rust#146758 (Stop linking rs{begin,end} objects on x86_64-*-windows-gnu) - rust-lang/rust#146778 (Use standard attribute logic for allocator shim) - rust-lang/rust#146849 (Reduce some uses of `LegacyBang`) - rust-lang/rust#147016 (fix doc comments to be more standard) - rust-lang/rust#147027 (Add new `tyalias` intra-doc link disambiguator) - rust-lang/rust#147031 (mbe: Simplify check_redundant_vis_repetition) - rust-lang/rust#147058 (Ignore more failing ui tests for GCC backend) Failed merges: - rust-lang/rust#147046 (Rename `rust.use-lld` to `rust.bootstrap-override-lld`) r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until now, x86_64-pc-windows-gnu linked
rsbegin.oandrsend.ojust like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced.Today the things are different and these startup/end objects harm other features, like
build-std. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1.The files are still shipped in case downstream crates expect them, as in case of the unmaintained
xargo.Fixes #146739