-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
README: document when libgit2 is statically linked #1073
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I found the previous paragraph in the current version of the README quite confusing. The text follows my understanding of https://github.com/rust-lang/git2-rs/blob/f1f09cee7b332d2b494d14d46fd2ec8e5203916a/libgit2-sys/build.rs#L25-L56. I hope it's OK to hide the bit about `zlib` under the case where an "appropriate version of libgit2 cannot be found". Feel free to edit this further. Cc: commit 59a81ca I looked into this because I was confused that, after upgrading the Homebrew version of libgit2, my builds of https://github.com/martinvonz/jj started linking libgit2 statically. I'm planning to try enabling `vendored_libgit2` in that project permanently and recommending that people use the environment variable `LIBGIT2_NO_VENDOR=1` if they want dynamic linking.
ehuss
approved these changes
Jul 26, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
ilyagr
added a commit
to ilyagr/jj
that referenced
this pull request
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 jj-vcs#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 jj-vcs#4115.
ilyagr
added a commit
to ilyagr/jj
that referenced
this pull request
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 jj-vcs#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 jj-vcs#4115.
ilyagr
added a commit
to ilyagr/jj
that referenced
this pull request
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 jj-vcs#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 jj-vcs#4115.
ilyagr
added a commit
to ilyagr/jj
that referenced
this pull request
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 jj-vcs#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 jj-vcs#4115.
ilyagr
added a commit
to jj-vcs/jj
that referenced
this pull request
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I found the previous paragraph in the current version of the README quite confusing.
The text follows my understanding of
git2-rs/libgit2-sys/build.rs
Lines 25 to 56 in f1f09ce
zlib
under the case where an "appropriate version of libgit2 cannot be found". Feel free to edit this further.Cc: commit 59a81ca
I looked into this because I was confused that, after upgrading the Homebrew version of libgit2, my builds of https://github.com/martinvonz/jj started linking libgit2 statically. I'm planning to try enabling
vendored_libgit2
in that project permanently and recommending that people use the environment variableLIBGIT2_NO_VENDOR=1
if they want dynamic linking.