Download LLVM from CI to bootstrap (linux-only to start) #76349
Conversation
Mark-Simulacrum
force-pushed
the
dl-llvm
branch
2 times, most recently
from
d63f9e8
to
f0f3a69
Compare
jyn514
added
T-bootstrap
Mark-Simulacrum
force-pushed
the
dl-llvm
branch
2 times, most recently
from
a0e47cd
to
8d3c74f
Compare
Mark-Simulacrum
changed the title
Mark-Simulacrum
force-pushed
the
dl-llvm
branch
from
8d3c74f
to
2119ca0
Compare
|
I still want to test this with alt builds and on macOS (I don't have a Windows computer to test on right now, and suspect that this won't work as-is there due to LLVM being statically linked rather than shared on Windows in CI). Since the option is off by default we can technically land it before #76332 -- it just won't work to enable it. Probably best to wait after that lands, though. r? @pietroalbini but anyone else should feel free to approve too |
At least for MinGW, linking LLVM dynamically should work fine when using libc++ instead of libstdc++ (because of the hangs mentioned in 3rd item at Upgrading MinGW on the CI). |
…troalbini Add rust-dev component to support rustc development This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM, CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date, and carries all necessary patches. This is a separate PR from rust-lang#76349 because it needs to land before that one, since we want a master build with the full CI LLVM to be available for easier testing.
Mark-Simulacrum
changed the title
Mark-Simulacrum
force-pushed
the
dl-llvm
branch
from
343b4b1
to
7f05cfc
Compare
|
I've confirmed this works on linux. I plan to spend some time trying to make it work on macOS, but I would like to get this in contributor's hands to the extent possible soon (since it's a major help for people who can use it and are first-time contributors). It is still off by default until we can make it work on all tier-1 platforms, though. |
jyn514
added
the
S-waiting-on-review
There was a problem hiding this comment.
Code-wise, would it be possible to minimize the impact of this new option? For example could there be one option that recognizes the boolean flag and then sets llvm-config based on the convention that x.py downloads to? That way there'd just be one place in rustbuild (ideally) that the flag is checked.
Mark-Simulacrum
force-pushed
the
dl-llvm
branch
2 times, most recently
from
4c1aefd
to
b3bf722
Compare
|
@bors r=alexcrichton We weren't uplifting properly because while ThinLTO enabled shared linking, it did not do so properly by setting the link-shared configuration option. |
|
📌 Commit 2e87a6e has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions, checks-azure |
|
👀 Test was successful, but fast-forwarding failed: 422 Update is not a fast forward |
|
Gah I forgot about that bors bug, but looks like it didn't actually push to master... @bors r=alexcrichton retry |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit 2e87a6e has been approved by |
…hton Download LLVM from CI to bootstrap (linux-only to start) This follows rust-lang#76332, adding support for using CI-built LLVM rather than building it locally. This should essentially "just work," but is left off by default in this PR. While we can support downloading LLVM for multiple host triples, this currently only downloads it for the build triple. That said, it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though, so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after rust-lang#76332, we can fix this behavior to reduce downloads further.
|
☀️ Test successful - checks-actions, checks-azure |
Implemented in rust-lang/rust#76349
…hton Always try to promote shared LLVM to the sysroot Even when LLVM is not generally participating in a shared link with rustc, we will likely still link to the shared dylib from rust-lld, so we still need to promote it. This reverts part of rust-lang#76349; my expectation that the link-shared rule was sufficient was likely wrong. Hopefully fixes rust-lang#76698. r? `@alexcrichton`
Implemented in rust-lang/rust#76349
This follows #76332, adding support for using CI-built LLVM rather than building it locally. This should essentially "just work," but is left off by default in this PR.
While we can support downloading LLVM for multiple host triples, this currently only downloads it for the build triple. That said, it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though, so this should cover most use cases.
Currently this downloads LLVM for the last bors-authored commit in the
git log. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332, we can fix this behavior to reduce downloads further.