Skip to content
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

Revert "Fix custom relative libdir." #59668

Closed
wants to merge 1 commit into from

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
Collaborator

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

@@ -518,8 +516,7 @@ impl Step for Rustc {
.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
Contributor

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
Contributor

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