rustbuild: Fix copying duplicate crates into the sysroot #42263
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
Mark-Simulacrum
added
the
S-waiting-on-review
|
Changes look good to me. Giving slight priority since this unblocks other work. @bors r+ p=1 |
|
📌 Commit 684e33a has been approved by |
Mark-Simulacrum
added
S-waiting-on-bors
|
⌛ Testing commit 684e33a with merge f212c5d... |
|
💔 Test failed - status-appveyor |
|
Failure seems potentially non-spurious/related, but not sure: |
Mark-Simulacrum
added
S-waiting-on-author
|
Hm I got that once when working on this and brushed it off, I'll have to investigate again what's up |
alexcrichton
force-pushed
the
fix-copies
branch
2 times, most recently
from
75755c7 to
e925003
Compare
|
@bors: r=Mark-Simulacrum |
|
📌 Commit e925003 has been approved by |
|
⌛ Testing commit e925003 with merge faa233c... |
|
💔 Test failed - status-travis |
|
@bors retry Presumably spurious timeout; it's not entirely clear what happened though. Raw log is empty, but the actual build log does show results. https://travis-ci.org/rust-lang/rust/jobs/236953993 |
|
⌛ Testing commit e925003 with merge 8dcf95c... |
|
💔 Test failed - status-travis |
|
@bors retry
|
|
⌛ Testing commit e925003 with merge 7ca8f09... |
|
💔 Test failed - status-travis |
|
macOS timed out after 3 hours. |
|
Hm... well, seeing as other platforms are fine, I'm going to assume just macs being flaky as usual. @bors retry |
rustbuild: Fix copying duplicate crates into the sysroot After compiling a project (e.g. libstd, libtest, or librustc) rustbuild needs to copy over all artifacts into the sysroot of the compiler it's assembling. Unfortunately rustbuild doesn't know precisely what files to copy! Today it has a heuristic where it just looks at the most recent version of all files that look like rlibs/dylibs and copies those over. This unfortunately leads to bugs with different versions of the same craet as seen in #42261. This commit updates rustbuild's strategy of copying artifacts to work off the list of artifacts produced by `cargo build --message-format=json`. The build system will now parse json messages coming out of Cargo to watch for files being generated, and then it'll only copy over those precise files. Note that there's still a bit of weird logic where Cargo prints that it's creating `libstd.rlib` where we actually want `libstd-xxxxx.rlib`, so we still do a bit of "most recent file" probing for those. This commit should take care of the crates.io dependency issues, however, as they're all copied over precisely. Closes #42261
|
💔 Test failed - status-travis |
|
Same issue... (3 out of 5 macOS jobs timed out after three hours) |
|
@alexcrichton will investigate tomorrow. Not retrying until then. |
|
Comparing time spent for Job 53342.36 "macOS x86_64 check" (timed out), with Job 53342.28 "Linux x86_64" (finished in ~1.5 hours). Why is the compiler rebuilt five times on macOS?!
The last good build on
|
|
Thanks for the analysis @kennytm! Definitely looks like a bug in the rebuilding logic. |
After compiling a project (e.g. libstd, libtest, or librustc) rustbuild needs to copy over all artifacts into the sysroot of the compiler it's assembling. Unfortunately rustbuild doesn't know precisely what files to copy! Today it has a heuristic where it just looks at the most recent version of all files that look like rlibs/dylibs and copies those over. This unfortunately leads to bugs with different versions of the same craet as seen in rust-lang#42261. This commit updates rustbuild's strategy of copying artifacts to work off the list of artifacts produced by `cargo build --message-format=json`. The build system will now parse json messages coming out of Cargo to watch for files being generated, and then it'll only copy over those precise files. Note that there's still a bit of weird logic where Cargo prints that it's creating `libstd.rlib` where we actually want `libstd-xxxxx.rlib`, so we still do a bit of "most recent file" probing for those. This commit should take care of the crates.io dependency issues, however, as they're all copied over precisely. Closes rust-lang#42261
|
@bors: r=Mark-Simulacrum |
|
📌 Commit 2dab1e2 has been approved by |
|
⌛ Testing commit 2dab1e2 with merge 42dc068... |
|
💥 Test timed out |
|
Actually it is running normally (I've checked that the stageN-rustc are built only twice, correctly). Bors created the commit at 2144Z (as seen on AppVeyor) but due to incident in Travis the build only started 9 hours after the merge (around 0600Z), and then bors canceled it at 0838Z. |
|
@alexcrichton as the test failed, mind amending the typo?
|
|
@bors retry Travis incident, which I don't think is resolved yet, but let's populate the queue, doesn't hurt in this case - not fast at timing out. |
|
💔 Test failed - status-travis |
|
@alexcrichton Will investigate; this was a timeout. |
|
@bors: retry All logs have our builds finishing in under three hours, so I guess a travis bug? |
|
The program is run twice simultaneously in the same job (e.g. https://travis-ci.org/rust-lang/rust/jobs/237985910), halving the build speed. It is strange the cancel happens 5 hours later, not the usual 3 hours. This has to be Travis bug because the symptom is right at the beginning of the log (worker info printed twice): and we can see interleaving timestamps like The Travis Status Page is currently all-green, probably a retry could make it disappear. |
rustbuild: Fix copying duplicate crates into the sysroot After compiling a project (e.g. libstd, libtest, or librustc) rustbuild needs to copy over all artifacts into the sysroot of the compiler it's assembling. Unfortunately rustbuild doesn't know precisely what files to copy! Today it has a heuristic where it just looks at the most recent version of all files that look like rlibs/dylibs and copies those over. This unfortunately leads to bugs with different versions of the same crate as seen in #42261. This commit updates rustbuild's strategy of copying artifacts to work off the list of artifacts produced by `cargo build --message-format=json`. The build system will now parse json messages coming out of Cargo to watch for files being generated, and then it'll only copy over those precise files. Note that there's still a bit of weird logic where Cargo prints that it's creating `libstd.rlib` where we actually want `libstd-xxxxx.rlib`, so we still do a bit of "most recent file" probing for those. This commit should take care of the crates.io dependency issues, however, as they're all copied over precisely. Closes #42261
|
☀️ Test successful - status-appveyor, status-travis |
|
While it's not actually rebuilt, rustbuild attempts to build everything 2-4 times, which generates logs that are extremely hard to read. I have confirmed this in at least all PR build, of course including this PR. @alexcrichton is this an intended behavior? |
After compiling a project (e.g. libstd, libtest, or librustc) rustbuild needs to
copy over all artifacts into the sysroot of the compiler it's assembling.
Unfortunately rustbuild doesn't know precisely what files to copy! Today it has
a heuristic where it just looks at the most recent version of all files that
look like rlibs/dylibs and copies those over. This unfortunately leads to bugs
with different versions of the same crate as seen in #42261.
This commit updates rustbuild's strategy of copying artifacts to work off the
list of artifacts produced by
cargo build --message-format=json. The buildsystem will now parse json messages coming out of Cargo to watch for files being
generated, and then it'll only copy over those precise files.
Note that there's still a bit of weird logic where Cargo prints that it's
creating
libstd.rlibwhere we actually wantlibstd-xxxxx.rlib, so we stilldo a bit of "most recent file" probing for those. This commit should take care
of the crates.io dependency issues, however, as they're all copied over
precisely.
Closes #42261