Bug #104156 for XML-LibXML: exact version check generates a useless warning, breaking scripts

Fri May 01 20:40:33 2015 vincent [...] vinc17.net - Ticket created

Subject:

exact version check generates a useless warning, breaking scripts

LibXML.pm does an exact version check: { my ($runtime_version) = LIBXML_RUNTIME_VERSION() =~ /^(\d+)/; if ( $runtime_version < LIBXML_VERSION ) { warn "Warning: XML::LibXML compiled against libxml2 ".LIBXML_VERSION. ", but runtime libxml2 is older $runtime_version\n"; } } This is a problem for Linux distributions, because the distributed version may have been compiled with a newer libxml2 version, and a warning is generated, which breaks scripts that check for errors.

Sat May 02 01:36:14 2015 SHLOMIF [...] cpan.org - Correspondence added

On Fri May 01 20:40:33 2015, vincent@vinc17.net wrote: Show quoted text

> LibXML.pm does an exact version check: > > { > my ($runtime_version) = LIBXML_RUNTIME_VERSION() =~ /^(\d+)/; > if ( $runtime_version < LIBXML_VERSION ) { > warn "Warning: XML::LibXML compiled against libxml2 > ".LIBXML_VERSION. > ", but runtime libxml2 is older $runtime_version\n"; > } > } > > This is a problem for Linux distributions, because the distributed > version may have been compiled with a newer libxml2 version, and a > warning is generated, which breaks scripts that check for errors.

First of all, why are you using a lower libxml2 version than the one the distributed version was compiled against? Shouldn't it be the one packaged for the Linux distribution? Secondly, I believe you can trap and override this warning using $SIG{__WARN__}. Finally though, I am open for a patch that disables this check if there's a package-scope variable set. E.g: «««« BEGIN { $XML::LibXML::disable_runtime_library_version_check = 1 ; } use XML::LibXML; »»»» Please let me know what you think. Regards, -- Shlomi Fish

Sat May 02 01:36:15 2015 The RT System itself - Status changed from 'new' to 'open'

Sat May 02 04:23:43 2015 vincent [...] vinc17.net - Correspondence added

From:

vincent [...] vinc17.net

Le Sam 02 Mai 2015 01:36:14, SHLOMIF a écrit : Show quoted text

> First of all, why are you using a lower libxml2 version than the one > the distributed version was compiled against?

Yes, because of an important regression in the latest libxml2 version, which gives errors on valid XML documents that have external XML entities: https://bugzilla.gnome.org/show_bug.cgi?id=737840 Show quoted text

> Shouldn't it be the one packaged for the Linux distribution?

It is packaged, but I can't use it due to this regression (for which there seems to be no good workaround). And there is no versioned dependency (which would have avoided the automatic upgrade of XML::LibXML) because the new libxml2 library is entirely ABI-compatible with the old one. Show quoted text

> Secondly, I believe you can trap and override this warning using > $SIG{__WARN__}.

This could be a workaround, but I would need to modify all my scripts. Show quoted text

> Finally though, I am open for a patch that disables this check if > there's a package-scope variable set. E.g: > > «««« > BEGIN { $XML::LibXML::disable_runtime_library_version_check = 1 ; } > use XML::LibXML; > »»»»

This would be better, but there would be the same problem: the need to modify all the scripts (if the variable is not set by default), unless there is also a way to do that globally, e.g. via a config file or an environment variable. Now I'm wondering why there is such a check at all. Library versioning should take care of such version problems and give an error only when need be.

Sat May 02 07:09:47 2015 SHLOMIF [...] cpan.org - Correspondence added

Hi Vincent, On Sat May 02 04:23:43 2015, vincent@vinc17.net wrote: Show quoted text

> Le Sam 02 Mai 2015 01:36:14, SHLOMIF a écrit :

> > First of all, why are you using a lower libxml2 version than the one > > the distributed version was compiled against?

> > Yes, because of an important regression in the latest libxml2 version, > which gives errors on valid XML documents that have external XML > entities: > > https://bugzilla.gnome.org/show_bug.cgi?id=737840 >

> > Shouldn't it be the one packaged for the Linux distribution?

> > It is packaged, but I can't use it due to this regression (for which > there seems to be no good workaround). And there is no versioned > dependency (which would have avoided the automatic upgrade of > XML::LibXML) because the new libxml2 library is entirely ABI- > compatible with the old one. >

> > Secondly, I believe you can trap and override this warning using > > $SIG{__WARN__}.

> > This could be a workaround, but I would need to modify all my scripts. >

> > Finally though, I am open for a patch that disables this check if > > there's a package-scope variable set. E.g: > > > > «««« > > BEGIN { $XML::LibXML::disable_runtime_library_version_check = 1 ; } > > use XML::LibXML; > > »»»»

> > This would be better, but there would be the same problem: the need to > modify all the scripts (if the variable is not set by default), unless > there is also a way to do that globally, e.g. via a config file or an > environment variable. > > Now I'm wondering why there is such a check at all. Library versioning > should take care of such version problems and give an error only when > need be.

The problem is that XML::LibXML may make use of features in the more recent libxml2 , against which it was compiled, and so break with the older versions. What I suggest you to do is to build a new version of XML::LibXML against the older library and use that instead of the system XML::LibXML. You can consult the following documents for insights: * https://metacpan.org/pod/ExtUtils::MakeMaker * https://metacpan.org/pod/local::lib Otherwise, I feel that the warning is there for a reason , and that it should be kept there. If you wish, you may opt to remove it from the installed .pm file manually (but I'd really recommend installing a new XML::LibXML distribution). Regards, -- Shlomi Fish

Sat May 02 17:45:52 2015 vincent [...] vinc17.net - Correspondence added

From:

vincent [...] vinc17.net

Le Sam 02 Mai 2015 07:09:47, SHLOMIF a écrit : Show quoted text

> The problem is that XML::LibXML may make use of features in the more > recent libxml2 , against which it was compiled, and so break with the > older versions.

No, if the new version of the libxml2 library has new features, it is not possible to run a program against an older version of the library, thanks to library versioning. See http://www.gnu.org/software/libtool/manual/html_node/Versioning.html or https://autotools.io/libtool/version.html In the present case, libxml2 2.9.1 and libxml2 2.9.2 are compatible in both ways (forward and backward) because they have the same "current" and "age" values. Basically, 2.9.2 is here just a bug-fix release; it doesn't introduce any new feature. So, whether one links to 2.9.1 or to 2.9.2, the program will still work (up to bugs). So, the warning is completely useless because the check for new features (incompatibilities) is already done via library versioning.

Wed May 06 06:59:55 2015 CARNIL [...] cpan.org - Cc CARNIL added

Wed May 06 07:12:42 2015 gregoa [...] cpan.org - Cc GREGOA added

Thu May 07 09:36:47 2015 SHLOMIF [...] cpan.org - Correspondence added

Hi vincent, I am not convinced that this is an actual issue with the module and like I said there are some workarounds and/or fixes you can follow. So I'm going to close this issue as "REJECTED". You should make sure to manage the versions of the various software components on your system in a better way. Regards, -- Shlomi Fish

Thu May 07 09:36:49 2015 SHLOMIF [...] cpan.org - Status changed from 'open' to 'rejected'

Thu May 07 10:10:18 2015 vincent [...] vinc17.net - Correspondence added

From:

vincent [...] vinc17.net

Le Jeu 07 Mai 2015 09:36:47, SHLOMIF a écrit : Show quoted text

> You should make sure to manage the versions of the various software > components on your system in a better way.

The way Debian and other Linux distributions are doing is the right way and guaranteed to work (if no bugs). There's no better way.

Fri May 08 02:38:02 2015 SREZIC [...] cpan.org - Correspondence added

On 2015-05-07 09:36:47, SHLOMIF wrote: Show quoted text

> Hi vincent, > > I am not convinced that this is an actual issue with the module and > like I said there are some workarounds and/or fixes you can follow. So > I'm going to close this issue as "REJECTED". You should make sure to > manage the versions of the various software components on your system > in a better way.

I can follow Vincent's reasoning and think that a check like this would be better (untested): my ($runtime_version) = LIBXML_RUNTIME_VERSION() =~ /^(\d+)/; if ( int($runtime_version/100) < int(LIBXML_VERSION()/100) ) { warn "Warning: XML::LibXML compiled against libxml2 ".LIBXML_VERSION. ", but runtime libxml2 is older $runtime_version\n"; } Regards, Slaven

Fri May 08 08:00:50 2015 vincent [...] vinc17.net - Correspondence added

From:

vincent [...] vinc17.net

Le Ven 08 Mai 2015 02:38:02, SREZIC a écrit : Show quoted text

> I can follow Vincent's reasoning and think that a check like this > would be better (untested): > > my ($runtime_version) = LIBXML_RUNTIME_VERSION() =~ /^(\d+)/; > if ( int($runtime_version/100) < int(LIBXML_VERSION()/100) ) { > warn "Warning: XML::LibXML compiled against libxml2 > ".LIBXML_VERSION. ", but runtime libxml2 is older $runtime_version\n"; > }

This would be a bit better (not tested), but won't solve the general problem in case one wants to use an even older library. The reason is that what is actually done is the use of symbol versioning, so that it is allowed to use an older library if the software doesn't use the new features. See: http://stackoverflow.com/questions/4032373/linking-against-an-old-version-of-libc-to-provide-greater-application-coverage (this one is about libc, but it is the same with libxml2). For instance, concerning the XML/LibXML/LibXML.so installed on my machine: $ objdump -p /usr/lib/x86_64-linux-gnu/perl5/5.20/auto/XML/LibXML/LibXML.so [...] Version References: required from libc.so.6: 0x06969194 0x00 17 GLIBC_2.14 0x0d696914 0x00 14 GLIBC_2.4 0x09691974 0x00 07 GLIBC_2.3.4 0x09691a75 0x00 03 GLIBC_2.2.5 required from libxml2.so.2: 0x0f4cabc8 0x00 21 LIBXML2_2.6.18 0x08f4c7b6 0x00 20 LIBXML2_2.5.6 0x0f4cabd7 0x00 19 LIBXML2_2.6.27 0x0f4cabd0 0x00 18 LIBXML2_2.6.20 0x0f4cabc4 0x00 16 LIBXML2_2.6.14 0x08f4cab3 0x00 15 LIBXML2_2.6.3 0x0f4cabc7 0x00 13 LIBXML2_2.6.17 0x08f4c7b9 0x00 12 LIBXML2_2.5.9 0x08f4c7b8 0x00 11 LIBXML2_2.5.8 0x0f4cabc5 0x00 10 LIBXML2_2.6.15 0x08f4c7b2 0x00 09 LIBXML2_2.5.2 0x08f4cab6 0x00 08 LIBXML2_2.6.6 0x08f4cab0 0x00 06 LIBXML2_2.6.0 0x08f4c7b7 0x00 05 LIBXML2_2.5.7 0x08f4c7b0 0x00 04 LIBXML2_2.5.0 0x0f4c8be0 0x00 02 LIBXML2_2.4.30 So, it just needs a lixbml2 library version that provides the symbols up to 2.6.18 (which is probably libxml2 2.6.18 here), even though XML::LibXML was built against a much more recent version of libxml2. In Debian, there's a dependency on libxml2 >= 2.7.4 because symbol versioning in libxml2 was introduced in this version: libxml2 (2.7.4.dfsg-1) unstable; urgency=low [...] * debian/libxml2.symbols: Change symbols file to use newly introduced symbol versioning * debian/rules: bump shlibs to current version. -- Mike Hommey <glandium@debian.org> Thu, 10 Sep 2009 23:04:35 +0200