Skip to content
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 1 commit into from
Jul 26, 2024

Conversation

ilyagr
Copy link
Contributor

@ilyagr ilyagr commented Jul 25, 2024

I found the previous paragraph in the current version of the README quite confusing.

The text follows my understanding of

let https = env::var("CARGO_FEATURE_HTTPS").is_ok();
let ssh = env::var("CARGO_FEATURE_SSH").is_ok();
let vendored = env::var("CARGO_FEATURE_VENDORED").is_ok();
let zlib_ng_compat = env::var("CARGO_FEATURE_ZLIB_NG_COMPAT").is_ok();
// Specify `LIBGIT2_NO_VENDOR` to force to use system libgit2.
// Due to the additive nature of Cargo features, if some crate in the
// dependency graph activates `vendored` feature, there is no way to revert
// it back. This env var serves as a workaround for this purpose.
println!("cargo:rerun-if-env-changed=LIBGIT2_NO_VENDOR");
let forced_no_vendor = env::var_os("LIBGIT2_NO_VENDOR").map_or(false, |s| s != "0");
if forced_no_vendor {
if try_system_libgit2().is_err() {
panic!(
"\
The environment variable `LIBGIT2_NO_VENDOR` has been set but no compatible system libgit2 could be found.
The build is now aborting. To disable, unset the variable or use `LIBGIT2_NO_VENDOR=0`.
",
);
}
// We've reached here, implying we're using system libgit2.
return;
}
// To use zlib-ng in zlib-compat mode, we have to build libgit2 ourselves.
let try_to_use_system_libgit2 = !vendored && !zlib_ng_compat;
if try_to_use_system_libgit2 && try_system_libgit2().is_ok() {
// using system libgit2 has worked
return;
}
. 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.

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.
Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@ehuss ehuss added this pull request to the merge queue Jul 26, 2024
Merged via the queue into rust-lang:master with commit cb32b01 Jul 26, 2024
7 checks passed
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants