You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
Cargo/libgit2 crashes on Apple Silicon M1 when installed through homebrew
This is definitely a weird one - I've been unable to reproduce this outside of homebrew's environment, but it's happening rather consistently when attempting to take actions in homebrew's cargo root.
The most obvious symptom of this is the rather oddly phrased error message seen below
Updating crates.io index
warning: spurious network error (2 tries remaining): failed to lock file '$CARGO_HOME/registry/index/git.luolix.top-1ecc6299db9ec823/.git/refs/remotes/origin/master.lock' for writing: ; class=Os (2)
warning: spurious network error (1 tries remaining): failed to lock file '$CARGO_HOME/registry/index/git.luolix.top-1ecc6299db9ec823/.git/refs/remotes/origin/master.lock' for writing: ; class=Os (2)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`
Caused by:
failed to lock file '$CARGO_HOME/registry/index/git.luolix.top-1ecc6299db9ec823/.git/refs/remotes/origin/master.lock' for writing: ; class=Os (2)
($CARGO_HOME being homebrew's own cargo root - $HOME/Library/Caches/Homebrew/cargo_cache)
The error message naturally just means "lock file already exists", though this wasn't incredibly obvious at first glance...
Upon further investigation, on the first run without the lock file in place, cargo actually crashes in the middle of a libgit2 call (crash dump available below).
At this point I realized that I could simply ask cargo to use the git cli instead of libgit2, and after putting more time than I care to admit hitting my head against this, I was more than happy to take that option. Hopefully this information will help someone else to have less frustrations, or hopefully even fully diagnose and fix the issue at play.
Steps
Edit homebrew formula to use aarch64 compiler for bootstrapping (see notes)
Install the lightly customized rust formula, building from source, using the HEAD release (brew install -s --HEAD rust)
Attempt to install another brew formula that uses rust's build environment (brew install -s --HEAD tree-sitter, for instance, though others also fail)
Observe the failure described above
Possible Solution(s) / Workaround
Change cargo config to use the git cli for interactions.
(printf '[net]\ngit-fetch-with-cli = true' >> ~/Library/Caches/Homebrew/cargo_cache/config, in this case)
Notes
Output of cargo version: cargo 1.50.0
Diff to rust formula
diff --git a/Formula/rust.rb b/Formula/rust.rb
index 64d42a594e..68b1926dd1 100644
--- a/Formula/rust.rb+++ b/Formula/rust.rb@@ -42,8 +42,13 @@ class Rust < Formula
resource "cargobootstrap" do
on_macos do
# From https://github.com/rust-lang/rust/blob/#{version}/src/stage0.txt
- url "https://static.rust-lang.org/dist/2020-11-19/cargo-1.48.0-x86_64-apple-darwin.tar.gz"- sha256 "ce00d796cf5a9ac8d88d9df94c408e5d7ccd3541932a829eae833cc8e57efb15"+ if Hardware::CPU.arch == :arm64+ url "https://static.rust-lang.org/dist/2020-12-20/cargo-nightly-aarch64-apple-darwin.tar.gz"+ sha256 "740d16056af3061fd22e9b5bc900483779a4a603f5e63750593d465ee58e019b"+ else+ url "https://static.rust-lang.org/dist/2020-11-19/cargo-1.48.0-x86_64-apple-darwin.tar.gz"+ sha256 "ce00d796cf5a9ac8d88d9df94c408e5d7ccd3541932a829eae833cc8e57efb15"+ end
end
on_linux do
@@ -78,17 +83,9 @@ class Rust < Formula
else
args << "--release-channel=stable"
end
- # Cross-compile arm64 with x86_64 bootstrap compiler.- if Hardware::CPU.arch == :arm64- args << "--build=x86_64-apple-darwin"- args << "--host=aarch64-apple-darwin"- args << "--target=aarch64-apple-darwin"- system "./configure", *args- system "arch", "-x86_64", "make"- else- system "./configure", *args- system "make"- end++ system "./configure", *args+ system "make"
system "make", "install"
resource("cargobootstrap").stage do
I believe this has been fixed via #9009 (via rust-lang/git2-rs#646, via libgit2/libgit2#5746). The fix landed in Rust 1.50 (rust-lang/rust#80322) on Dec 24. It looks like the nightly snapshot in your diff is just before that landed, so I'm guessing that nightly is too old. It looks like people are working on updating 1.49 (Homebrew/homebrew-core#68089), and it looks like they have a more recently nightly, so I think things should be working there.
I'm going to close this for now, but if you continue to have problems with the updated versions, feel free to leave a comment.
Problem
Cargo/libgit2 crashes on Apple Silicon M1 when installed through homebrew
This is definitely a weird one - I've been unable to reproduce this outside of homebrew's environment, but it's happening rather consistently when attempting to take actions in homebrew's cargo root.
The most obvious symptom of this is the rather oddly phrased error message seen below
(
$CARGO_HOME
being homebrew's own cargo root -$HOME/Library/Caches/Homebrew/cargo_cache
)The error message naturally just means "lock file already exists", though this wasn't incredibly obvious at first glance...
Upon further investigation, on the first run without the lock file in place, cargo actually crashes in the middle of a libgit2 call (crash dump available below).
At this point I realized that I could simply ask cargo to use the git cli instead of libgit2, and after putting more time than I care to admit hitting my head against this, I was more than happy to take that option. Hopefully this information will help someone else to have less frustrations, or hopefully even fully diagnose and fix the issue at play.
Steps
rust
formula, building from source, using the HEAD release (brew install -s --HEAD rust
)brew install -s --HEAD tree-sitter
, for instance, though others also fail)Possible Solution(s) / Workaround
Change cargo config to use the git cli for interactions.
(
printf '[net]\ngit-fetch-with-cli = true' >> ~/Library/Caches/Homebrew/cargo_cache/config
, in this case)Notes
Output of
cargo version
:cargo 1.50.0
Diff to rust formula
macOS Crash Dump
The text was updated successfully, but these errors were encountered: