libvirt @7.6.0: libvirt-lxc.0.dylib provides version 0.0.0

[inflatador (Brian King)]

Hello, when attempting to compile code that has a dependency for libvirt, I get the error

"requires version 6007.0.0 or later, but libvirt-lxc.0.dylib provides version 0.0.0
Abort trap: 6"

I'm not sure if this actually indicates an error with the port, but I did notice a number of libraries reporting that they provide version 0.0.0 when I checked /opt/local/lib/libvirt-* with otool -L (see attached).

I am running Mac OS X 10.13.

[inflatador (Brian King)]

output of "otool -L /opt/local/lib/libvirt-*"

[ryandesign (Ryan Carsten Schmidt)]

The creator of any library is free to define its versioning scheme. 6007.0.0 is a valid library minor version number, as is 0.0.0. It is the responsibility of the developers of the project to exercise care to ensure that their library versions proceed in a sensible manner, for example to ensure that the library minor versions do not decrease from one release to the next. Unfortunately, the developers of libvirt appear not to have exercised that care in this case.

What appears to have happened here is that the developers of libvirt decided to switch from the autotools build system to the meson build system. For a time both build systems were offered and MacPorts stuck with the autotools system since that was less work than switching, but then libvirt deleted its autotools build system so we were forced to switch. This happened when the port was updated to version 7.0.0 in [50f6b87e76adfc829c92802d3ec8b91aab53ca8c/macports-ports]. autotools (libtool) has a very particular way of handling library version numbers, so it would be incumbent upon the developers of any project switching from libtool to some other library build system to ensure that the existing library versioning scheme is preserved. The developers of libvirt didn't.

This is unfortunately an extremely common mistake made by I would guess most projects that switch from autotools to something newer, and there have been a lot of projects over recent years that have switched from autotools to cmake or meson. Unfortunately, usually by the time the mistake is noticed it has been published in a release of the software and the developers are often uninterested in fixing the problem.

I don't see a bug report filed about this with the developers of libvirt. If you would like to file a bug report with them so that they might return to the previous library minor version numbering scheme in a future release, the URL to do so is ​https://gitlab.com/libvirt/libvirt/-/issues.

If they will not fix their library versioning in the foreseeable future, then the workaround that we probably have to employ is that every port that links with a libvirt library that has not had its version or revision increased since we updated to libvirt 7.0.0 should have its revision increased to rebuild it against the new (lower) library minor version number. If the software with which you encountered the error was not built by MacPorts, then you will need to rebuild it from source separately.

[ryandesign (Ryan Carsten Schmidt)]

I've updated the libvirt port to version 9.0.0. Library minor versions are still at 0.0.0. Did anyone ever file a bug report with them about this?