vcpkg claims that libxml2 2.11.9 is not compatible with 2.7.4

[szhorvat]

Describe the bug

vcpkg claims that libxml2 2.11.9 is not compatible with 2.7.4, which is incorrect. find_package(LibXml2 2.7.4) results in the following output:

  Could not find a configuration file for package "LibXml2" that is
  compatible with requested version "2.7.4".

  The following configuration files were considered but not accepted:

    C:/vcpkg/installed/x64-windows-static-md/share/libxml2/libxml2-config.cmake, version: 2.11.9

I noticed this issue in the igraph CI tests. This is how igraph looks for libxml2:

https://github.com/igraph/igraph/blob/e940ab737938dfdd4518164c866b2599af40856f/etc/cmake/dependencies.cmake#L74

With debug output:

https://github.com/igraph/igraph/blob/9036af6b96b266bb72fa9b41f52e8e124b44d58b/etc/cmake/dependencies.cmake#L76-L77

Link to CI test issue:

https://dev.azure.com/igraph-team/igraph/_build/results?buildId=8240&view=logs&j=dc2fa7f2-c2a5-5af8-ba1c-9621505790a7&t=dcba228e-5c56-53e5-8cff-603ef5cc76bd&l=323

Environment

• OS: Windows

• Compiler: VS 2022 v17.12.0, current windows-latest on Azure

• OS: macOS 14.7

• Compiler: Apple Clang 16.0

CMake 3.31 on both.

To Reproduce

I cannot reproduce this issue with a libxml2 that is installed separately from vcpkg.

On macOS, here's a small project file to reproduce:

# CMakeLists.txt

cmake_minimum_required(VERSION 3.31)
project(Foo)

find_package(LibXml2 2.7.4)

Then use

mkdir build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=.../vcpkg/scripts/buildsystems/vcpkg.cmake

I am not able to test on Windows directly.

Expected behavior

I expect version 2.11.x to be accepted when looking for version 2.7.4. But in fact it fails when looking for any version that is not of the form 2.11.x (this includes 2.10.0 or 2.12.0).

This is what I expect, and what I see with a libxml2 that is not installed with vcpkg:

Found LibXml2: /opt/local/lib/libxml2.dylib (found suitable version "2.13.5", minimum required is "2.7.4")

Failure logs
—

Additional context
—

CC @ntamas

[dg0yt]

FTR in vcpkg, the exported cmake config is used to resolve find_package(LibXml2). The config mode version policy is determined by libxml2 as ExactVersion:
https://gitlab.gnome.org/GNOME/libxml2/-/blob/master/CMakeLists.txt?ref_type=heads#L607-611

You can try to pass a version range to find_package.

[szhorvat]

This issue is specific to vcpkg though. If I install libxml2 directly from sources, then install it and delete its pkg-config file, find_package(LibXml2 2.7.4) still finds it correctly. The output from my example script is

-- Found LibXml2: /Users/szhorvat/lxml2/lib/libxml2.dylib (found suitable version "2.14.0", minimum required is "2.7.4")

Does find_package() also use some other methods for discovery?

Specifying a version range doesn't work, unfortunately. When using vcpkg, this happens:

  Could not find a configuration file for package "LibXml2" that is
  compatible with requested version range "2.7...2.15".

  The following configuration files were considered but not accepted:

    /Users/szhorvat/Repos/vcpkg/installed/arm64-osx/share/libxml2/libxml2-config.cmake, version: 2.11.9
    /opt/local/lib/cmake/libxml2/libxml2-config.cmake, version: unknown

Call Stack (most recent call first):
  /Users/szhorvat/Repos/vcpkg/scripts/buildsystems/vcpkg.cmake:813 (include)
  CMakeLists.txt:4 (find_package)

When installing libxml2 without vcpkg, this happens (but the package is still found):

CMake Warning (dev) at /opt/local/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:450 (message):
  `find_package()` specify a version range but the module LibXml2 does not
  support this capability.  Only the lower endpoint of the range will be
  used.
Call Stack (most recent call first):
  /opt/local/share/cmake-3.31/Modules/FindLibXml2.cmake:113 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:4 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found LibXml2: /Users/szhorvat/lxml2/lib/libxml2.dylib (found suitable version "2.14.0", minimum required is "2.7")

[szhorvat]

@nwellnhof, any comments on this?

[szhorvat]

Does find_package() also use some other methods for discovery?

Yes, it appears that CMake has a built-in Find Module for libxml2: https://cmake.org/cmake/help/latest/module/FindLibXml2.html

Is the ExactVersion compatibility mode really intended, @nwellnhof ?

[dg0yt]

This issue is specific to vcpkg though.

Yes, because of using CMake config even when you don't ask for it.

CMake has a built-in Find Module.

Vcpkg doesn't use it. Find modules poorly support transitive usage requirements, in particular when subject to configuration. Often they fail also on multi-config setup. Users which do single-config dynamic-linkage Linux or macOS usually don't notice these limitations. They are real nevertheless.

I still wonder if the port should be fixed at all as long as upstream says "same version".

[szhorvat]

I still wonder if the port should be fixed at all as long as upstream says "same version".

Let's wait for a response from the upstream developer, whom I pinged above. The requirement is strange and it seems inconsistent with the compatibility that libxml2 offered so far ...

[nwellnhof]

Is the ExactVersion compatibility mode really intended, @nwellnhof ?

I'm not really a CMake expert and I have no idea. You'd have to ask Markus Rickert who contributed initial CMake support here: https://gitlab.gnome.org/GNOME/libxml2/-/commit/2a2c38f3

Feel free to open a libxml2 issue.

[ntamas]

igraph upstream here. From our side the intention was to depend on the specified libxml2 version or any later version. We cannot pin igraph to a specific libxml2 version because igraph is packaged in several Linux distributions and we have no control over the version of libxml2 that they ship these distros with. Also, the particular find_package(...) line in igraph's CMake configuration has been around for a long time (igraph's history spans back to CMake 2.x) and the behaviour of find_package(...) has changed several times in that period.

Personally, I had no idea that in config mode the package may override the default behaviour of find_package(...) such that find_package(libxml2 x.y.z) means "exactly x.y.z" in one environment and "at least x.y.z" in another environment. I am happy to replace the offending find_package(...) call with whatever is needed in igraph to make things work. The intention is definitely to depend on libxml2 2.7.4 or later.

[dg0yt]

For now, I simply want to know libxml2's official policy on versioning and (source level) compatibility.
Then we can adjust the CMake code accordingly.

[nwellnhof]

The official policy is SameMajorVersion. This is now fixed in libxml2: https://gitlab.gnome.org/GNOME/libxml2/-/commit/2ef1beb38b2d98b40f5b8b3430a45e5944688386

[Osyotr]

The official policy is SameMajorVersion. This is now fixed in libxml2: https://gitlab.gnome.org/GNOME/libxml2/-/commit/2ef1beb38b2d98b40f5b8b3430a45e5944688386

Is the official policy the same for libxslt?
https://gitlab.gnome.org/GNOME/libxslt/-/blob/master/CMakeLists.txt?ref_type=heads#L509