-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Split the rustc target libraries into separate rustc-dev component #65474
Conversation
This splits out a rustc-dev component with the compiler crates, and keeps the status quo of default installed files on nightly. The default changing to not install compiler libraries by default is left for a future pull request. However, on stable and beta, this does remove the compiler libraries from the set of libraries installed by default, as they are never needed there (per our stability story, they "cannot" be used).
I would appreciate confirmation from @jethrogb as to musl being fixed, but I personally think we can likely approve and land this. |
At this point, I can only confirm that this try build had the appropriate fix for SGX. I'd be happy to look at other artifacts once they are built. |
Oh I see the instructions for using dev-static now. I won't be able to try that until tomorrow. |
I ran the following commands, which completed succesfully:
|
Okay, sounds like we're ready to go ahead. @pietroalbini, this should be ready for approval (basically confirming that we've tested sufficiently, I think; code changes have already been pre-approved by me, they're not mine). |
Should we make a post on users/reddit asking people to test non-x86 targets? |
We, uh, can. I feel like that's going too far though? I guess I'm not opposed. |
I have no idea what happened with the MSVC toolchain; what I could see in the build log is that Miri would build fine when rustc-dev is installed, but then it would fail to run with no error. I think this is the behavior Windows shows when a shared library is missing? But I am just guessing here. |
I ran Miri CI with this experimental toolchain and everything is green. Looks like whatever issue there was is fixed now. |
I've set the arbitrary landing deadline as Monday -- if by then there are no complaints on the internals thread I will approve this. |
Ok, it's now Monday, let's land this! @bors r+ |
📌 Commit 7ccf492 has been approved by |
@bors rollup=never p=1 |
⌛ Testing commit 7ccf492 with merge e9a1afca9daba3dcd5539a2349207edff8fca1a8... |
@bors retry |
Split the rustc target libraries into separate rustc-dev component This is re-applies a squashed version of #64823 as well as including #65337 to fix bugs noted after merging the first PR. The second PR is confirmed as fixing windows-gnu, and presumably also fixes other platforms, such as musl (i.e. #65335 should be fixed); `RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup toolchain install nightly-2019-10-16` can be installed to confirm that this is indeed the case.
💥 Test timed out |
@bors retry windows dist build timed out again... |
Split the rustc target libraries into separate rustc-dev component This is re-applies a squashed version of #64823 as well as including #65337 to fix bugs noted after merging the first PR. The second PR is confirmed as fixing windows-gnu, and presumably also fixes other platforms, such as musl (i.e. #65335 should be fixed); `RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup toolchain install nightly-2019-10-16` can be installed to confirm that this is indeed the case.
☀️ Test successful - checks-azure |
Yes finally. |
Hm, now I am again seeing weird failures for Miri on Windows:
Any idea why the Miri binary might exit immediately without printing anything? |
Looks like that exit code is |
That would be odd since this PR should have produced an identical looking sysroot to before... Can you check that |
The oddest thing is that it worked when I tired it with the experimental toolchain. Ah wait, I have an idea... maybe we need a matching cargo for the toolchain... |
Yes that was it; the failure had nothing to do with this PR and everything with rust-lang/rustup#1575. |
pr65474 minimizes the amount of files needed for the install of a rust-std component by not merging certain dev-header files and other instable components. more information: rust-lang/rust#64823 rust-lang/rust#65474 I opted for +-r1 and dropped keywords, for testing. Also included pr66103, it shouldn't hurt anyone. Signed-off-by: Steffen Kuhn <nielson2@yandex.com>
pr65474 minimizes the amount of files needed for the install of a rust-std component by not merging certain dev-header files and other instable components. more information: rust-lang/rust#64823 rust-lang/rust#65474 I opted for +-r1 and dropped keywords, for testing. Also included pr66103, it shouldn't hurt anyone. Signed-off-by: Steffen Kuhn <nielson2@yandex.com> Closes: #464 Signed-off-by: Mikhail Pukhlikov <cynede@gentoo.org>
pr65474 minimizes the amount of files needed for the install of a rust-std component by not merging certain dev-header files and other instable components. more information: rust-lang/rust#64823 rust-lang/rust#65474 Signed-off-by: Steffen Kuhn <nielson2@yandex.com>
This is re-applies a squashed version of #64823 as well as including #65337 to fix bugs noted after merging the first PR.
The second PR is confirmed as fixing windows-gnu, and presumably also fixes other platforms, such as musl (i.e. #65335 should be fixed);
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup toolchain install nightly-2019-10-16
can be installed to confirm that this is indeed the case.