FS#49457 - [libxml2] python3 bindings are broken
Attached to Project:
Arch Linux
Opened by Abdó Roig-Maranges (abdo) - Tuesday, 24 May 2016, 09:13 GMT
Last edited by Jan de Groot (JGC) - Thursday, 26 May 2016, 11:21 GMT
Opened by Abdó Roig-Maranges (abdo) - Tuesday, 24 May 2016, 09:13 GMT
Last edited by Jan de Groot (JGC) - Thursday, 26 May 2016, 11:21 GMT
|
Details
Description:
python3 bindings are broken again. Additional info: * libxml2 2.9.3+0+gbdec218 Steps to reproduce: $ python -c 'import libxml2' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.5/site-packages/libxml2.py", line 9326 XML_CHAR_ENCODING_ASCII XML_T ^ SyntaxError: invalid syntax |
This task depends upon
Closed by Jan de Groot (JGC)
Thursday, 26 May 2016, 11:21 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in package using workarounds in PKGBUILD.
Thursday, 26 May 2016, 11:21 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in package using workarounds in PKGBUILD.
I spent some time trying to understand where the hell this line comes from in the upstream build. This piece of python is auto-generated.
But in the meantime, a fix for this particular thing is a one-liner. just replace the offending line with
XML_CHAR_ENCODING_ASCII = 22
This is caused by MAKEFLAGS. Everytime I build libxml2 the python bindings are different. In the build logs I see the python class generator is called 3 times in parallel.
Also, the testsuite doesn't work for python 3.x and errors don't seem to be fatal, so this wasn't caught when upgrading libxml2. In fact, this bug could apply to any version of libxml2.
Multiple target rules is a very misleading feature of GNU make, because it really produces one identical single-target rule for each one of the targets. You end up having several rules with one target each, but whose command touches all files. This is racy as hell on parallel builds.
If this theory is right, invoking with make -j1 will prevent one generator racing against each other and making a mess.
Then, I imagine that the non-deterministic output may have to do with python data structures (python dicts have no defined order), and would be harmless, unless you care about deterministic builds.
Do you plan to send a patch upstream for the build system? If you don't I'll prepare something later. Regarding the dicts... It does not bug me enough to fix it.
A fan in of $(GENERATED) depending on a new phony target,
and that then depending on the original dependencies,
will stop make running generator.py multiple times.
Syntax error fixed.