Il 12/08/22 21:32, Giovanni Mascellani ha scritto:
Thanks for filing the bug. It seems that Boost builds fine with xsltproc and libxslt1version 1.1.34 (instead of 1.1.35 currently in sid). I am not an XSLT master and it seems that nobody upstream has noticed yet, maybe because 1.1.35 is still relatively recent. I'll file a bug upstream to see if they can work out a solution.
I sent an email to the Boost development mailing list[1], which is unfortunately not getting any attention for the moment.
[1] https://lists.boost.org/Archives/boost/2022/08/253369.phpIn the meantime, I also created a minimal test case, so that somebody who knows about XSLT can look at that without having to deal with the Boost building system.
In order to reproduce the bug, you have to: 1. Download the attached reproduce.tar.gz2. Extract it in /tmp. You can also use another directory, but then you have to fix an absolute path, se below.
3. Install docbook-xml, docbook-xsl and xsltproc.4. If you didn't extract in /tmp, edit the absolute path in reproduce/boostbook/boostbook_catalog.xml appropriately.
5. Go to /tmp/reproduce, or wherever you extracted it, and launch ./execute.sh (which is just a wrapper over the appropriate xsltproc command line).
If you already have xsltproc and libxslt1.1 version 1.1.35, then you will see a lot of errors of this form:
runtime error: file boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.
If you still have version 1.1.34 (or downgrade), then everything will work and the output file output.boostbook will be generated (a couple of warnings will be printed, but they are not problematic; or, at least, they are a different problem).
If anybody knows how to fix libxslt or the boostbook XSLTs, then please let me know!
Thanks, Giovanni. -- Giovanni Mascellani <g.mascell...@gmail.com>
reproduce.tar.gz
Description: application/gzip
