Error running tests after upgrade to libgit2-sys 0.12.23+1.2.0

[taurr]

In https://github.com/cargo-generate/cargo-generate, after upgrading git2 to 0.13.22, tests no longer run due to

Git Error: invalid version 0 on git_proxy_options; class=Invalid (3)

Tracing this error leads to the upgrade of libgit2-sys, and seems to be an old issue: https://www.google.com/search?q=Git+Error%3A+invalid+version+0+on+git_proxy_options

[alexcrichton]

Can you provide some more information about how to reproduce and how minimize perhaps? The only usage of git_proxy_options should be constructed with the version field set to 1, so I'm not sure where this would be coming from.

[taurr]

Nor am I unfortunately, but it started failing immediately after upgrading to git2 version 0.13.21, and only on my linux setup (Manjoro/Arch) - not on windows 10.

After some searching and messing around I found that it ties down to the use of libgit2-sys version 0.12.23+1.2.0. A single revision back on that lib, and everything is ok again. Obviously it's a little difficult to downgrade once the offending version is on the system as the little + in the version allows it to pick the newer one :-)

[taurr]

As for reproduction, I was running cargo test against https://github.com/cargo-generate/cargo-generate

All tests succeed on all but my Manjaro system which was not updated in between the succeding/failing upgrade of our git2 dependency.

[srhb]

I did the mind-numbing bisect of libgit2 to find out what the culprit is, hoping that someone can pick up from here and realize what went wrong.

It appears the problem was introduced here:

libgit2/libgit2#6012

Specifically in libgit2/libgit2@72df17c

Doing a "slightly-sloppy-but-hey-it-builds"-revert on top of v1.3.0 appears to fix it: srhb/libgit2@7d08801

[kim]

It might be that an incompatible version of libgit2 from the system package manager is picked up. Maybe try building with the vendored-libgit2 feature?

[srhb]

You got me on the right track -- the problem was the opposite. I was pulling in a too-old version of git2-rs (and transitively the -sys component) which was incompatible with the newer libgit2 I was linking against. I had the problem backwards. Thank you! 😄

[saethlin]

I think this is an ABI break in libgit2. I (and many other Arch users) ran into exactly the same problem (my case is mentioned above this comment, rust-lang/crater#598), in most/all cases due to building a project with a dependency on a libgit2-sys intended for libgit2-1.1.0, but linking in libgit2 1.3.0. I feel like that ought to work, it's a minor version bump. So as far as I can tell, either libgit2 doesn't have ABI stability, or the libgit2 project is having a rough time trying to provide ABI stability.

In either case, I think this line:

git2-rs/libgit2-sys/build.rs

Line 17 in f1a3e12

if let Ok(lib) = cfg.atleast_version("1.3.0").probe("libgit2") {

should be changed to exactly_version or perhaps range_version in case there's a newer patch release on the system.

Things work fine at the moment on the latest version of this crate(s), but it's possible that is only because it is caught up to the latest libgit2 release, so either a matching version or a vendored version is used. At the moment. I would like some more insurance that code continues to build as time passes 😅

[jonasmalacofilho]

@saethlin,

So as far as I can tell, either libgit2 doesn't have ABI stability, [...]

This seems to be the case (libgit2/libgit2#6210 (comment)).

As that comment mentions, the precise API & ABI guarantees are documented in libgit2/libgit2/docs/api-stability.md. Relating to ABI stability, this is what they currently say (emphasis mine):

• Our ABI is only considered stable through a minor release.

  • Our ABI consists of actual symbol names in the library, the function signatures, and the actual layout of structures. These are only stable within minor releases, they are not stable within major releases (yet).
  • Since many FFIs use ABIs directly (for example, .NET P/Invoke or Rust), this instability is unfortunate.
  • In a future major release, we will begin providing ABI stability throughout the major release cycle.
  • ABI changes will be noted specially within a release's changelog.

• Point releases are generally only for bugfixes, and generally do not include new features. This means that point releases generally do not include new APIs. Point releases will never break API, systems API or ABI compatibility.

[taurr]

I believe and trust that this has been fixed by @joshtriplett in the commit mentioned above.

The problem was very repeatable on my machine, and has gone. Likewise there does not seem to be any new observations.

If it is still an issue, we can either reopen, or create a new issue.