Re: [lmi] Should lmi use an xml catalog resolver?

[Vadim Zeitlin]

On Fri, 30 Oct 2020 20:39:16 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Kim built everything from scratch yesterday with cygwin, and her logs
GC> show a different set of "failed to load external entity" messages,
GC> with no chroot involved, of course.

 Sorry, it's apparently my build environment which is special and not
yours, after all: I also see such warnings in GitHub CI builds, see e.g.

https://github.com/let-me-illustrate/lmi/runs/1333943758?check_suite_focus=true#step:10:1131

GC> The count for Kim's log is 292. The error messages (more compact
GC> than mine above) begin:
GC> 
GC> Making install in doc
GC> make[1]: Entering directory 
'/opt/lmi/local/gcc_x86_64-w64-mingw32/xml-ad_hoc/libxslt/doc'
GC> Validating the HTML Web pages
GC> Validating the HTML Web pages
GC> warning: failed to load external entity "API.html"
GC> warning: failed to load external entity "bugs.html"
GC> warning: failed to load external entity "contribs.html"

It's strange that neither you nor Kim get the first error message from the
CI build, which is:

I/O error : Attempt to load network entity 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd

(could it be filtered out from the build log somehow?), and seems to be the
root explanation of the problem. This error seems to be due to the use of
"--nonet" xsltproc option in tests/docbook/Makefile.am and the absence of
the DTD on the local file system. The only strange thing is that there
don't seem to be any Debian package providing this DTD, even though it is
included in a few of them. The DTD is also present in tests/valid/dtds
subdirectory of libxml2 sources, so we could probably just set
XML_CATALOG_FILES environment variable to point there to avoid it. Should I
try doing this?

GC> In my most recent (chroot) log, the same section looks like this:
GC> 
GC> make[1]: Entering directory 
'/opt/lmi/local/gcc_x86_64-w64-mingw32/xml-ad_hoc/libxslt/doc'
GC> Rebuilding the HTML Web pages from xslt.html
GC> [...the preceding line repeats about a dozen times...]
GC> Validating the HTML Web pages
GC> /usr/bin/xmllint: relocation error: /usr/bin/xmllint: symbol 
xmlSchematronParse version LIBXML2_2.6.21 not defined in file libxml2.so.2 with 
link time reference

 This is annoying, we seem to be using system xmllint with our own
libraries that are incompatible with it (e.g. because we explicitly use
--without-schematron configure option, while system xmllint is built with
Schematron support).

 It doesn't change much, as validation still fails, just for a different
reason, but we still don't really care about it, but we probably should
avoid this, probably by setting the PATH when configuring libxslt in a way
to make sure that it finds xmllint that we've just built, instead of the
system one which it finds by default.

GC> make[1]: [Makefile:747: EXSLT/docs.html] Error 127 (ignored)
GC> [...the preceding four lines repeat numerous times...]
GC> 
GC> Kim's log doesn't contain any "Rebuilding" lines at all.

 This is because her Cygwin installation must not have xsltproc, so it isn't
found by libxslt configure and not used by their makefiles. I am less sure
about what to do here though, as xsltproc is built as part of building
libxslt itself, i.e. we'd have to build it and then configure again, which
doesn't seem worth it as we don't care about the docs anyhow.

GC> Does the
GC>   symbol xmlSchematronParse version LIBXML2_2.6.21 not defined in file 
libxml2.so.2 with link time reference
GC> suggest a problem that might have an obvious solution?

 Yes, I think so: we should set the PATH to use the correct xmllint binary.
Again, it's not going to change much in practice, so I'm not sure how
important is it to do it, but we could fix this.

GC> > but if there isn't, we can live with 244 extra lines in a 15000-line 
build log.
GC> That conclusion still stands: we can live with this problem, as it is
GC> merely a nuisance. I'm posting this update only to get the cygwin
GC> results on the historical record. With two very different systems,
GC> we both see many more "external entity" problems than formerly, and
GC> I'd guess that this is because we're now building a later release and
GC> perhaps using more of the autotools machinery than we did with tarballs.

 I'm still not totally sure why are these problems new, after all we built
these libraries previously as well. But, as you say that we can live with
this, I won't spend time on investigating this unless you ask me.

 And if we do anything at all here, I think we should fix using the wrong
xmllint (or, alternatively, ensure we don't use it at all). Please let me
know if you think it's worth doing.

 Thanks,
VZ

pgp6scbLJK6tt.pgp
Description: PGP signature