From 67cadf7946a1d802ad2cc538a29b7e52196a4af3 Mon Sep 17 00:00:00 2001 From: Ilya Grigoriev Date: Thu, 25 Jul 2024 17:42:28 -0700 Subject: [PATCH] cargo: enable vendored-libgit2, document how to properly dynamically 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. 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 https://github.com/rust-lang/git2-rs/pull/1073 This might be related to #4115. --- Cargo.toml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/Cargo.toml b/Cargo.toml index 631855ede50..4284a6abe18 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -48,7 +48,16 @@ dunce = "1.0.4" either = "1.13.0" esl01-renderdag = "0.3.0" futures = "0.3.30" -git2 = "0.18.3" +git2 = { version = "0.18.3", features = [ + # Do *not* disable this feature even if you'd like dynamic linking. Instead, + # set the environment variable `LIBGIT2_NO_VENDOR=1` if dynamic linking must + # be used (this will override the Cargo feature), and allow static linking + # in other cases. Rationale: If neither the feature nor the environment + # variable are set, `git2` may still decide to vendor `libgit2` if it + # doesn't find a version of `libgit2` to link to dynamically. See also + # https://github.com/rust-lang/git2-rs/commit/3cef4119f + "vendored-libgit2" +] } gix = { version = "0.63.0", default-features = false, features = [ "index", "max-performance-safe",