Arch Linux User Repository

I've added the additional arguments and now depend on libxml2-2.9. It build fine and tests run fine. Let's see if libxml2-2.9 soname problem will be fixed.

Build does complete when using @isl 's suggestion to use patchelf to fix the libxml2-2.9 SONAME and then update the build options in the PKGBUILD file. This does seem like the best way to get a clean build right now. It does seem that this other package should patch the SONAME issue so building against it is easy and IIRC that is the correct way to configure and use such a package.

@cmsigler I have got the same error than you

For now you can still build and install it if the failed use case doesn't affect you since it is only some tests failing. Unfortunately python 2 is no longer supported upstream and this is the last version I am able to compile so it's up to us to try and fix it.

Hi,

This pkg isn't crucial for my use. But like others have seen, it hasn't been able to build for me in a long time.

FYI, I tried building in a clean chroot this morning with no success. There's only one check error, so it's somewhat puzzling to me that upstream doesn't grok this problem and fix it(?). I see:

====================================================================== ERROR: test_html_prefix_nsmap (lxml.tests.test_etree.ETreeOnlyTestCase)

Traceback (most recent call last): File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/build/python2-lxml/src/lxml-lxml-4.9.4/src/lxml/tests/test_etree.py", line 3128, in test_html_prefix_nsmap self.assertEqual({}, el.nsmap) AttributeError: 'NoneType' object has no attribute 'nsmap'

====================================================================== FAIL: test_illegal_utf8_recover (lxml.tests.test_unicode.EncodingsTestCase)

Traceback (most recent call last): File "/usr/lib/python2.7/unittest/case.py", line 329, in run testMethod() File "/build/python2-lxml/src/lxml-lxml-4.9.4/src/lxml/tests/test_unicode.py", line 172, in test_illegal_utf8_recover self.assertEqual('\ufffd\ufffd\ufffd', tree.text) File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual raise self.failureException(msg) AssertionError: '\ufffd\ufffd\ufffd' != u'\ufffd\ufffd\ufffd'

Thank you for working on this AUR pkg :)

Clemmitt Sigler

Make aur/python2-lxml-bin

Don't care as it's used by 1 program only which I use rarely. If it crashes I'll check on it then

@vagelis This will result in runtime crashes when the problematic function is called by user programs, just as in the test run.

@is1 my workaround was to comment out the test.py in PKGBUILD and installation completed successfully.

@vagelis @patlefort For me it builds fine if libxml2 version 2.11 isn’t installed alongside libxml2-2.9, without any failing tests. Then /usr/lib/libxml2.so.2 points to /usr/lib/libxml2-2.9/libxml2.so.2.9.10 instead of the new library version. This was my configuration which may not work for other users and I’m sorry for the confusion this caused. libxml2-2.9 isn’t configured properly to work alongside the newer version because it hasn’t set its SONAME properly, so dynamically linking against this library is made more complicated even with correct compiler flags set. objdump -x /usr/lib/libxml2-2.9/libxml2.so.2.9.10 | grep -i soname gives libxml2.so.2, the same name as the new library version which shadows it. Also see ldconfig -p | grep libxml2. So a proper fix would be to patch this other package (or as a quick fix do patchelf --set-soname libxml2.so.2.9.10 /usr/lib/libxml2-2.9/libxml2.so.2.9.10; ldconfig).

It is however possible to build the package anyway by setting the runtime path in the linker options of gcc. To do this, both invocations of setup.py in PKGBUILD have to be run with these additional arguments: python setup.py ... --with-xml2-config=xml2-config-2.9 --with-xslt-config=xslt-config --auto-rpath. Then gcc puts full paths into the RUNPATH shared object property. This works for me, however, as the history of libtool shows, it may result in other problems.