Bug 263094

Summary: textproc/libxml2: incorrect LIBXML_VERSION_STRING in 2.9.13
Product: Ports & Packages Reporter: Mike Dalessio <mike.dalessio>
Component: Individual Port(s)Assignee: freebsd-desktop (Team) <desktop>
Status: Closed FIXED    
Severity: Affects Many People CC: adridg, diizzy
Priority: --- Flags: bugzilla: maintainer-feedback? (desktop)
Version: Latest   
Hardware: Any   
OS: Any   

Description Mike Dalessio 2022-04-06 15:28:39 UTC 
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!
Comment 1 Daniel Engberg freebsd_committer freebsd_triage 2022-04-06 19:32:38 UTC 
Hi Mike,

Thanks for reporting, I've reported to this bug to upstream

https://gitlab.gnome.org/GNOME/libxml2/-/issues/365

Best regards,
Daniel
Comment 3 Adriaan de Groot freebsd_committer freebsd_triage 2022-05-02 16:07:59 UTC 
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).