On FreeBSD 13, the `libxml2-2.9.13` package has an unexpected value in the `xmlParserVersion` global variable. Expected: "20913" Actual: "209013" (note the additional "0" between the "9" and "13"). For comparison, in the `libxml2-2.9.12` package this value was correctly set to "20912". Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262288 this appears to be happening because of this diff: ``` /** * LIBXML_VERSION: * * the version number: 1.2.3 value is 10203 */ -#define LIBXML_VERSION 20912 +#define LIBXML_VERSION 209013 /** * LIBXML_VERSION_STRING: * * the version number string, 1.2.3 value is "10203" */ -#define LIBXML_VERSION_STRING "20912" +#define LIBXML_VERSION_STRING "209013" ``` (see https://bz-attachments.freebsd.org/attachment.cgi?id=232326 for the full diff) I'm not sure why this has happened, but it's not uncommon for downstream users of libxml2 to sanity-check this string to make sure the version dynamically loaded is the same version that was compiled. See https://github.com/sparklemotion/nokogiri/issues/2506 for an example. I'd like to suggest that these strings should be set to "20913" in the next release of the package. Thank you!
Hi Mike, Thanks for reporting, I've reported to this bug to upstream https://gitlab.gnome.org/GNOME/libxml2/-/issues/365 Best regards, Daniel
Fixed upstream in https://gitlab.gnome.org/GNOME/libxml2/-/commit/94ac5e61f399759a5463c0505099222ed8f13a82
This was a consequence of two things: - upstream bug in how the CMake code calculated a version number to inject into the headers - switching to CMake-build in libxml2. The fix Daniel refers to is upstream in the CMake-build. Downstream we have discovered that there are (or can be, depending on options) circular dependencies when building libxml2 with CMake, so have rolled back to autotools -- which never had the problem in this PR. So I'm closing as "fixed", even though there was nothing intentional about it (in PORTREVISION 2).