cargo-c @0.9.16_0 broken by libgit2 update

[fhgwright (Fred Wright)]

bash-3.2$ port -v rev-upgrade
--->  Scanning binaries for linking errors
Could not open /opt/local/lib/libgit2.1.5.dylib: Error opening or reading file (referenced from /opt/local/bin/cargo-capi)
Warning: Error parsing file /opt/local/libexec/dbus-daemon-launch-helper: Error opening or reading file
--->  Found 4 broken files, matching files to ports
--->  Found 1 broken port:
     cargo-c @0.9.16_0
         /opt/local/bin/cargo-capi
         /opt/local/bin/cargo-cbuild
         /opt/local/bin/cargo-cinstall
         /opt/local/bin/cargo-ctest

bash-3.2$ port contents libgit2 | grep libgit2
Port libgit2 contains:
  /opt/local/lib/libgit2.1.6.4.dylib
  /opt/local/lib/libgit2.1.6.dylib
  /opt/local/lib/libgit2.dylib
  /opt/local/lib/pkgconfig/libgit2.pc

Either cargo-c needed a revbump for this, or it's linking against an overly specific libgit2 version.

[ryandesign (Ryan Carsten Schmidt)]

It is never a program's choice by what name to link with a library; it is always the library's choice. And libgit2 has evidently chosen to embed a three-part major version number in the library name. Anytime the library name changes, including due to a major version increase, every port that links with the library must be revbumped. Looks like ​the PR that updated libgit2 revbumped some ports that link with libgit2 but not cargo-c.

There is ​another PR to update cargo-c; that would take care of this issue for cargo-c.

If any other ports remain that link with libgit2 that have not been rebuilt (due to revbump or version increase) since the libgit2 update, they should be revbumped now.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

a three-part major version number in the library name

I suppose actually the library name without version is "libgit2" and that its version is now "1.6" (and there is a "1.6.4" symlink pointing to it, which is probably of no use to anybody).

I'll note that this major library version's minor library version is also 1.6.4:

% otool -L /opt/local/lib/libgit2.dylib | head -n2
/opt/local/lib/libgit2.dylib:
	/opt/local/lib/libgit2.1.6.dylib (compatibility version 1.6.0, current version 1.6.4)

This suggests a certain confusion on the part of the libgit2 developers about the difference between major and minor library version numbers on macOS. The matter should be brought to their attention with the hope that they might transition to more sane library versioning.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Both cargo and carg-c have been updated since this ticket was created, which should fix the problem.