Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Cached data restored from Rust's Cargo build is corrupted
See original GitHub issuehttps://github.com/rust-lang/cargo/issues/8603
It happened only on macOS executor.
It seems that file target/debug/deps/libserde_derive-797b01cb80d42716.dylib restored from cache is corrupted.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:14
- Comments:19 (7 by maintainers)
Top Results From Across the Web
Build on Github Action with macos-latest missing dependencies
As far as I see, it looks to be an issue with the GitHub cache action. After clearing the cache, and running cargo...
Read more >Cargo build hangs with " Blocking waiting for file lock on the ...
This happens when you run two compilations of the same project at the same time. The compiler uses a lock file to avoid...
Read more >Build Cache - The Cargo Book
Build cache. Cargo stores the output of a build into the "target" directory. By default, this is the directory named target in the...
Read more >2789-sparse-index - The Rust RFC Book
Fetching of crates (while online) by necessity downloads enough of the index to use them, and all this data remains cached for use...
Read more >The Cargo Book
Please see the Travis CI Rust documentation for more information. Build cache. Cargo shares build artifacts among all the packages of a single...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@zonyitoo Forcing the Mac runner to use GNU tar instead of BSD tar seems to fix the issue. Please consider using this as a workaround until we can devise a more permanent solution. It adds about 10-15 seconds to install GNU tar, but the savings from skipping the build greatly outweighs this.
Code change: https://github.com/dhadka/shadowsocks-rust/pull/1 Test run: https://github.com/dhadka/shadowsocks-rust/pull/1/checks
CC @dae
@maxim-lobanov Yes, we have such a plan.