[SOLVED] Problem building glib-2.70.0 in BLFS-11

hazel · 09-21-2021, 12:52 PM

glib now builds with meson and ninja instead of autotools. I'm building it with the recommended dependencies including xslt, but this makes ninja crash near the end of the run. The last messages I get are

Code:

[1109/1132] Generating gapplication-man with a custom command
FAILED: docs/reference/gio/gapplication.1
/bin/xsltproc --nonet --stringparam man.output.quietly 1 --stringparam
funcsynopsis.style ansi --stringparam man.th.extra1.suppress 1
--stringparam man.authors.section.enabled 0 --stringparam
man.copyright.section.enabled 0 -o docs/reference/gio/gapplication.1
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
../docs/reference/gio/gapplication.xml
I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity
"http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
cannot parse
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
[1114/1132] Compiling C object tests/onceinit.p/onceinit.c.o
ninja: build stopped: subcommand failed.

I can't quite work out what is happening here. There's an xsltproc command but it uses --nonet so it shouldn't be trying to get stuff of the internet. So what's this http url doing? And why is it crashing?

glib is an absolutely foundational library. Loads of packages use it. So until I can get it to build, I am pretty much stuck.

PS: It occurs to me that this could perhaps be a race condition. I believe ninja always uses all available cores and I have 4. Do you think if I used -j1, it would work better?

pan64 · 09-21-2021, 01:10 PM

I don't think -j1 will help, but [obviously] you can try that.
I/O error may mean disk full, HDD/SSD related error too, but I think in this case it wanted to download a stylesheet ("http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl") which was disabled by --nonet (therefore could not continue).

hazel · 09-21-2021, 01:31 PM

I don't think it can be any kind of disk error. If it was, it would be showing up all over the place. This is quite specific and reproducible. I'm beginning to wonder if I made some kind of error in the earlier docbook build. There's a lot of commands in that which create local databases. It's easy to make a mistake when copying and pasting that kind of stuff.

I think tomorrow, I'll try rebuilding that, and then have another go at glib. And also try a single core build. That certainly can't do any harm.

Keith Hedger · 09-22-2021, 05:29 AM

did you do the post install stuff for docbook-ssl?

Code:

if [ ! -d /etc/xml ];then
	install -v -m755 -d /etc/xml
fi
if [ ! -f /etc/xml/catalog ]; then
	xmlcatalog --noout --create /etc/xml/catalog||true
fi

xmlcatalog --noout --add "rewriteSystem" "https://cdn.docbook.org/release/xsl-nons/1.79.2" "/usr/share/xml/docbook/xsl-stylesheets-nons-1.79.2" /etc/xml/catalog
xmlcatalog --noout --add "rewriteURI" "https://cdn.docbook.org/release/xsl-nons/1.79.2" "/usr/share/xml/docbook/xsl-stylesheets-nons-1.79.2" /etc/xml/catalog
xmlcatalog --noout --add "rewriteSystem" "https://cdn.docbook.org/release/xsl-nons/current" "/usr/share/xml/docbook/xsl-stylesheets-nons-1.79.2" /etc/xml/catalog
xmlcatalog --noout --add "rewriteURI" "https://cdn.docbook.org/release/xsl-nons/current" "/usr/share/xml/docbook/xsl-stylesheets-nons-1.79.2" /etc/xml/catalog
xmlcatalog --noout --add "rewriteSystem" "http://docbook.sourceforge.net/release/xsl/current" "/usr/share/xml/docbook/xsl-stylesheets-nons-1.79.2" /etc/xml/catalog
xmlcatalog --noout --add "rewriteURI" "http://docbook.sourceforge.net/release/xsl/current" "/usr/share/xml/docbook/xsl-stylesheets-nons-1.79.2" /etc/xml/catalog

hazel · 09-22-2021, 08:17 AM

I did but, as I said above, I might have made a mistake with all that copying and pasting. It's fiddly work. I think I'd better rebuild and reinstall the docbook-ssl package, then try to rebuild glib. I'll report back afterwards.

hazel · 09-23-2021, 06:38 AM

You were right, Keith. In fact I hadn't completed the installation for either docbook-xml or docbook-xsl. But those pages really are confusing and the second one is definitely ambiguous when read with a text-mode browser (as you must do at this stage unless you are building in chroot). I have just cross-checked using FF and I can see now from the formatting which bits are conditional and which are not. I think the wording should make this clearer. For example the second part of the installation of docbook-xml could read:

Code:

In order to utilize DocBook XML DTD V4.5 when any version 4.x is requested in the System Identifier, you need 
to add additional statements to the catalog files. However, if you do have any of the DocBook XML DTD's referenced below 
already installed on your system, remove those entries from the for command below before proceeding (issue the commands as the root user):

Similarly for Docbook-xsl:

Code:

 If you are installing the current version of docbook-xsl-nons over a previous version of docbook-xsl, then remove the old rewrite entries in the catalog as the root user 
sed -i '/rewrite/d' /etc/xml/catalog
before continuing:

After I had done all this, glib compilation completed, so I have marked this as solved. But something rather weird occurred during this build which I have never seen in Linux before and which I would like to have some opinions on. I started as I normally would in this kind of situation by deleting the glib directory tree and untarring the source afresh. I'm virtually certain that I did this. But when I then tried to make a build subdirectory, I was told that it already existed! I went into it and ran meson and it did no configuration but just told me to run ninja. And when I did so, ninja just ran the last part of the build to make the documentation. In other words, the system had somehow recovered the old tree instead of using a new one.

Now I know that when you delete files, their content isn't deleted if there are existing links to them. But in this case there shouldn't have been. So how come I got the old tree back?

Keith Hedger · 09-23-2021, 08:19 AM

had a feeling that was the problem as had the same/similar a few builds back, glad you sorted it.

could you have umounted ghe disk before it finished deleting glib? is that a thing? if not i would say you were just having dumb day

hazel · 09-23-2021, 08:39 AM

I certainly couldn't have unmounted it; it's the root partition! Any way, I was very suspicious so I ran the package tests, which is a thing I don't usually do these days in LFS unless it's something crucial like gcc. Only three out of 200 failed (all in gio), so the final build was definitely successful.

Perhaps it was a poltergeist.