-
Notifications
You must be signed in to change notification settings - Fork 13k
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 #56944. #57116
Revert #56944. #57116
Conversation
@bors: r+ p=1000 |
📌 Commit 07f5dbc has been approved by |
⌛ Testing commit 07f5dbc with merge 72159884e284497696f5c682456d5655f198ed72... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors retry travis-ci/travis-ci#9696 Thanks 😒 |
Revert #56944. This should fix #57111, since #56944 is the only PR involving LLVM. #57111 is caused by both the rustc and rust-std tarballs providing libLLVM. r? @alexcrichton
☀️ Test successful - status-appveyor, status-travis |
I've opened #57286 to reland the original PR |
…atsakis bootstrap: Link LLVM as a dylib with ThinLTO (take 2) When building a distributed compiler on Linux where we use ThinLTO to create the LLVM shared object this commit switches the compiler to dynamically linking that LLVM artifact instead of statically linking to LLVM. The primary goal here is to reduce CI compile times, avoiding two+ ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll reuse the one ThinLTO step done by LLVM's build itself. Lots of discussion about this change can be found [here] and down. A perf run will show whether this is worth it or not! [here]: rust-lang#53245 (comment) --- This PR previously landed in rust-lang#56944, caused rust-lang#57111, and was reverted in rust-lang#57116. I've added one more commit here which should fix the breakage that we saw.
bootstrap: Link LLVM as a dylib with ThinLTO (take 2) When building a distributed compiler on Linux where we use ThinLTO to create the LLVM shared object this commit switches the compiler to dynamically linking that LLVM artifact instead of statically linking to LLVM. The primary goal here is to reduce CI compile times, avoiding two+ ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll reuse the one ThinLTO step done by LLVM's build itself. Lots of discussion about this change can be found [here] and down. A perf run will show whether this is worth it or not! [here]: #53245 (comment) --- This PR previously landed in #56944, caused #57111, and was reverted in #57116. I've added one more commit here which should fix the breakage that we saw.
This should fix #57111, since #56944 is the only PR involving LLVM.
#57111 is caused by both the rustc and rust-std tarballs providing libLLVM.
r? @alexcrichton