Support VS 2017 #42225
Support VS 2017 #42225
Conversation
brson
added
the
relnotes
|
I'm seeing issues in cmake that i want to investigate still. |
|
Ok, I think this patch is sufficient to fix rustc at least. Both gcc-rs and cmake still need to be updated to be able to find msbuild correctly. I'll file separate issues on those. |
|
@bors: r+ |
|
📌 Commit 88b9cf8 has been approved by |
|
The rustup patch failed on i686. |
|
@bors r- I'm still not confident about what's going on in i686 |
|
@bors r+ I want to see what bors thinks. |
|
📌 Commit 88b9cf8 has been approved by |
|
Rollup failure. PS: @frewsxcv please be careful when rolling up non-rollup priority PRs, inspect the PR comments before adding it to list. |
|
I'm not sure how the appveyor images are set up, but I suspect that after this lands we will be building Rust releases with VS 2017 instead of VS 2015. |
|
The error from the rollup is: The version number 15.0 corresponds to 2015, not 2017. And the linker is the only thing from VS we are running, right? |
|
Huh. That's not the error I expected :-/ |
No, 15 corresponds to 2017 and 14 corresponds to 2015.
This error is caused when you're running a cross linker but you forgot to add the host toolchain to |
src/librustc_trans/back/link.rs
Outdated
|
|
||
| if let Some(tool) = tool { | ||
| let path = tool.path().parent().map(|p| p.to_owned()); | ||
| (tool.to_command(), path) |
There was a problem hiding this comment.
The issue is right here. path is not supposed to be the directory with the linker, but rather the directory of the host toolchain (aka the folder with the linker whose target and host are both the same as the host of the linker that you are using). You'll have to teach gcc how to provide that information so you can pull it out here. And yes, you'll have to do this for VS 2017 too.
There was a problem hiding this comment.
Thanks for the review @retep998
Right. I have mistyped. The version number of the pasted text is 14.0 though, so it still corresponds to 2015. |
brson
force-pushed
the
vs2017
branch
2 times, most recently
from
5eee90f to
1d177d5
Compare
|
@bors r+ I want to see what bors thinks again. This is currently using a git replacement of the gcc crate. |
|
📌 Commit 1d177d5 has been approved by |
|
@bors r+ I changed the travis config to fail so this won't land with the crate replacement. |
|
📌 Commit 0e845bf has been approved by |
|
@bors r+ |
|
⌛ Testing commit 5ffc7bb with merge d390024... |
|
AppVeyor passed; I'm canceling this. https://ci.appveyor.com/project/rust-lang/rust/build/1.0.3454 |
|
This is ready to go now. |
|
@bors: r+ |
|
📌 Commit da100fe has been approved by |
VS 2017 updates Once rust-lang/rust#42225 lands rustup should build correctly under VS 2017. r? @Diggsey
VS 2017 updates Once rust-lang/rust#42225 lands rustup should build correctly under VS 2017. r? @Diggsey
|
@bors rollup We know that this passes AppVeyor, and Travis PR passed (and I think we've passed regular travis before). |
Support VS 2017 Fixes rust-lang#38584 This replaces all the MSVC linker logic with that from the 'gcc' crate. The code looks the same, but there could be regressions. I've only tested this with x86_64. r? @alexcrichton cc @vadimcn @retep998
Support VS 2017 Fixes rust-lang#38584 This replaces all the MSVC linker logic with that from the 'gcc' crate. The code looks the same, but there could be regressions. I've only tested this with x86_64. r? @alexcrichton cc @vadimcn @retep998
Support VS 2017 Fixes rust-lang#38584 This replaces all the MSVC linker logic with that from the 'gcc' crate. The code looks the same, but there could be regressions. I've only tested this with x86_64. r? @alexcrichton cc @vadimcn @retep998
Fixes #38584
This replaces all the MSVC linker logic with that from the 'gcc' crate. The code looks the same, but there could be regressions.
I've only tested this with x86_64.
r? @alexcrichton
cc @vadimcn @retep998