Skip to content

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Apr 3, 2019

This reverts #59341 which appears to have caused #59661 as a regression by accident. While we work that out let's get working nightlies again!

Closes #59661

@rust-highfive
Copy link
Contributor

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 3, 2019
@alexcrichton
Copy link
Member Author

r? @Mark-Simulacrum

.unwrap()
.join("bin")
.join(&exe);
// for the rationale about this rename check `compile::copy_lld_to_sysroot`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this part only should be reverted, could you check it on windows?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I don't have a Windows machine to test on, so I'm just trying to fix the regession quickly.

@phil-opp
Copy link
Contributor

phil-opp commented Apr 3, 2019

@alexcrichton I did some more investigation on #59661 and I'm no longer sure that rustc is at fault here, since all my projects that failed the Windows CI job today use cargo xbuild/xargo in some way. So the problem might as well be that the sysroot build tools do not copy the new directory. I will check this and report back as soon as I can!

@phil-opp
Copy link
Contributor

phil-opp commented Apr 3, 2019

Ok, I can now confirm that the problem was that #59341 broke cargo-xbuild/xargo. When we update these tools to copy bin/rustlib too everything works again.

Edit: It seems like projects that don't use cargo-xbuild/xargo are affected as well (see below).

@alexcrichton
Copy link
Member Author

@phil-opp is $root/bin/rustlib/x86_64-pc-windows-msvc/bin/rust-lld.exe present on Windows for today's nightly? If so that's a bug because it's not supposed to be in that location, it's supposed to be in $root/lib. While this may be fixable with cargo-xbuild/xargo, the tarballs do look buggy from their intended hierarchy.

@phil-opp
Copy link
Contributor

phil-opp commented Apr 3, 2019

is $root/bin/rustlib/x86_64-pc-windows-msvc/bin/rust-lld.exe present on Windows for today's nightly?

Yes, it is. I just booted up an old Windows machine to verify this on physical hardware.

Edit: Removed a previous claim that it worked in a project without xargo. It only worked because there was a rust-toolchain override with an older nightly in the project.

@phil-opp
Copy link
Contributor

phil-opp commented Apr 3, 2019

I just compiled a project that does not use cargo-xbuild/xargo with -C linker=rust-lld and it had the same "linker rust-lld not found" error with today's nightly.

@alexcrichton
Copy link
Member Author

Ok, I think we'll still want to fix this in that case (rather than taking no action at all). I haven't dug into the patch to see what a fix for both the original issue and this issue is, so for now I think we'll still want to revert.

@o01eg
Copy link
Contributor

o01eg commented Apr 3, 2019

I've added other PR to fix rust-lld placement.

@mati865
Copy link
Member

mati865 commented Apr 3, 2019

I should be able to test #59672 much later today or tomorrow early with windows-gnu toolchain.

@Mark-Simulacrum
Copy link
Member

@bors r+ (but not entirely clear to me based on discussion if we actually want to land this)

@bors
Copy link
Collaborator

bors commented Apr 3, 2019

📌 Commit afad743 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 3, 2019
@o01eg
Copy link
Contributor

o01eg commented Apr 3, 2019

@Mark-Simulacrum Could reverting small part be tested before?

@oli-obk
Copy link
Contributor

oli-obk commented Apr 3, 2019

@bors r- testing #59672 first

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 3, 2019
@alexcrichton
Copy link
Member Author

Ok on reviewing it seems like #59672 is likely to fix, so I'll close this in favor of that. Thanks for the quick fix @o01eg!

Centril added a commit to Centril/rust that referenced this pull request Apr 3, 2019
Revert rust-lld place changes

Fixes rust-lang#59661.

Instead of rust-lang#59668 it reverts only failed part.
Centril added a commit to Centril/rust that referenced this pull request Apr 3, 2019
Revert rust-lld place changes

Fixes rust-lang#59661.

Instead of rust-lang#59668 it reverts only failed part.
bors added a commit that referenced this pull request Apr 3, 2019
Revert rust-lld place changes

Fixes #59661.

Instead of #59668 it reverts only failed part.
@alexcrichton alexcrichton deleted the revert-it branch July 8, 2019 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants