-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Stop linking rs{begin,end} objects on x86_64-*-windows-gnu #146758
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@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.
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 |
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
Details
This 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
|
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`.
3b391e3
to
7eea65f
Compare
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. ) |
These commits modify compiler targets. |
I don't think this change needs any additional process if we are still shipping the 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 rust-lang#146739
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
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
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
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
Until now, x86_64-pc-windows-gnu linked
rsbegin.o
andrsend.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