Can't find libgit2 on Mac/Homebrew #4115
Labels
Comments
|
This seems to be a Homebrew issue, see #4080 (comment) aka (Homebrew/homebrew-core#177686). |
Ah, thanks. Best to close this then? |
|
We can keep it open until homebrew fixes it or close it whatever you prefer. |
|
Hey! I sent Homebrew/homebrew-core#177765 to fix, please check if that solves the issue. |
|
Yes, it appears to be fixed for me. Thank you! |
ilyagr
added a commit
to ilyagr/jj
that referenced
this issue
Jul 26, 2024
…link libgit2 This changes less than it seems. Our CI builds already mostly linked a vendored copy of libgit2. This is because before this commit, it turns out that `git2` could link `libgit2` *either* statically or dynamically based on whether it could find a version of libgit2 it liked to link dynamically. Our CI builds usually did not provide such a version AFAIK. This made the kind of binary `cargo install` would produce unpredictable and may have contributed to martinvonz#2896. Instead, if a packager wants to link `libgit2` dynamically, they should set an environment variable, as described inside the diff of this commit. I also think we should recommend static linking as `git2` is quite picky about the versions of `libgit2` it supports. See also rust-lang/git2-rs#1073 This might be related to martinvonz#4115.
ilyagr
added a commit
to ilyagr/jj
that referenced
this issue
Jul 26, 2024
…link libgit2 This changes less than it seems. Our CI builds already mostly linked a vendored copy of libgit2. This is because before this commit, it turns out that `git2` could link `libgit2` *either* statically or dynamically based on whether it could find a version of libgit2 it liked to link dynamically. Our CI builds usually did not provide such a version AFAIK. This made the kind of binary `cargo install` would produce unpredictable and may have contributed to martinvonz#2896. Instead, if a packager wants to link `libgit2` dynamically, they should set an environment variable, as described inside the diff of this commit. I also think we should recommend static linking as `git2` is quite picky about the versions of `libgit2` it supports. See also rust-lang/git2-rs#1073 This might be related to martinvonz#4115.
|
I think it's best to enable @nicholasjng (or anyone), let me know if this seems problematic. I'm not sure what Homebrew ended up doing, but I wanted to let you know about the environment variable in case you didn't know. rust-lang/git2-rs#1065 might also be relevant (though I'm not sure if that gets merged). |
ilyagr
added a commit
to ilyagr/jj
that referenced
this issue
Jul 26, 2024
…link libgit2 This changes less than it seems. Our CI builds already mostly linked a vendored copy of libgit2. This is because before this commit, it turns out that `git2` could link `libgit2` *either* statically or dynamically based on whether it could find a version of libgit2 it liked to link dynamically. Our CI builds usually did not provide such a version AFAIK. This made the kind of binary `cargo install` would produce unpredictable and may have contributed to martinvonz#2896. I was once very surprised when I did `brew upgrade libgit2` and then `cargo build --release` suddenly switched from building dynamically linked `jj` to the vendored version. Instead, if a packager wants to link `libgit2` dynamically, they should set an environment variable, as described inside the diff of this commit. I also think we should recommend static linking as `git2` is quite picky about the versions of `libgit2` it supports. See also rust-lang/git2-rs#1073 This might be related to martinvonz#4115.
ilyagr
added a commit
to ilyagr/jj
that referenced
this issue
Jul 28, 2024
…link libgit2 This changes less than it seems. Our CI builds already mostly linked a vendored copy of libgit2. This is because before this commit, it turns out that `git2` could link `libgit2` *either* statically or dynamically based on whether it could find a version of libgit2 it liked to link dynamically. Our CI builds usually did not provide such a version AFAIK. This made the kind of binary `cargo install` would produce unpredictable and may have contributed to martinvonz#2896. I was once very surprised when I did `brew upgrade libgit2` and then `cargo build --release` suddenly switched from building dynamically linked `jj` to the vendored version. Instead, if a packager wants to link `libgit2` dynamically, they should set an environment variable, as described inside the diff of this commit. I also think we should recommend static linking as `git2` is quite picky about the versions of `libgit2` it supports. See also rust-lang/git2-rs#1073 This might be related to martinvonz#4115.
ilyagr
added a commit
that referenced
this issue
Jul 28, 2024
…link libgit2 This changes less than it seems. Our CI builds already mostly linked a vendored copy of libgit2. This is because before this commit, it turns out that `git2` could link `libgit2` *either* statically or dynamically based on whether it could find a version of libgit2 it liked to link dynamically. Our CI builds usually did not provide such a version AFAIK. This made the kind of binary `cargo install` would produce unpredictable and may have contributed to #2896. I was once very surprised when I did `brew upgrade libgit2` and then `cargo build --release` suddenly switched from building dynamically linked `jj` to the vendored version. Instead, if a packager wants to link `libgit2` dynamically, they should set an environment variable, as described inside the diff of this commit. I also think we should recommend static linking as `git2` is quite picky about the versions of `libgit2` it supports. See also rust-lang/git2-rs#1073 This might be related to #4115.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Steps to Reproduce the Problem
brew upgradefor libgit2Expected Behavior
jjworks after the upgrade.Actual Behavior
While upgrading other packages, Homebrew reports:
(see also Homebrew/homebrew-core#177686)
jjis now broken with a dyld error:Specifications
jj0.19.0,libgit21.7.2 -> 1.8.1 (appears to be broken by upgrade)The text was updated successfully, but these errors were encountered: