Version: (using KDE 4.3.1) Compiler: g++ 4.2.4 OS: Linux Installed from: Compiled From Sources We recently upgraded to glibc 2.10.1 (from Red Hat's sources) in UHU-Linux, and I have not been able to package kdelibs successfully ever since. 4.3.1, 4.3 branch (@1029684) and trunk (same rev) all hang when meinproc4 is invoked to create CheckXML.1 (around 98% of the make process). It seems it's waiting for a futex indefinitely.
Here's the last few lines of make output (also includes the output from the system once I finally terminated meinproc4) kio_help4(10063) KBzip2Filter::compress: bzCompress returned 4 kio_help4(10063) KBzip2Filter::terminate: bzCompressEnd returned 0 [ 97%] Built target webdav-handbook Scanning dependencies of target checkXML-manpage-man-checkXML [ 97%] Generating checkXML.1 Writing checkXML.1 for refentry ../../bin/meinproc4.shell: line 4: 10076 Terminated LD_LIBRARY_PATH=/var/uhubuild/work/compile/build/lib/./:/usr/lib:/var/uhubuild/work/compile/build/lib/.:/usr/lib/qt4/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} "/var/uhubuild/work/compile/build/bin/meinproc4" "$@" make[2]: *** [doc/checkXML/checkXML.1] Error 143 make[1]: *** [doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/all] Error 2 make: *** [all] Error 2
I have glibc 2.10.1 and have other issues (bug 196207) but I can't reproduce this. It may be instructive to run make with "VERBOSE=1" so we can see the exact command line passed to meinproc4. Also I'm pretty sure we depend on DocBook for at least part of this so you might want to make sure your versions are up-to-date.
This is all I have about this: make -f doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/build.make doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/depend make[2]: Entering directory `/var/uhubuild/work/compile/build' cd /var/uhubuild/work/compile/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /var/uhubuild/work/compile /var/uhubuild/work/compile/doc/checkXML /var/uhubuild/work/compile/build /var/uhubuild/work/compile/build/doc/checkXML /var/uhubuild/work/compile/build/doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/DependInfo.cmake --color= Dependee "/var/uhubuild/work/compile/build/doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/DependInfo.cmake" is newer than depender "/var/uhubuild/work/compile/build/doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/depend.internal". Scanning dependencies of target checkXML-manpage-man-checkXML make[2]: Leaving directory `/var/uhubuild/work/compile/build' make -f doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/build.make doc/checkXML/CMakeFiles/checkXML-manpage-man-checkXML.dir/build make[2]: Entering directory `/var/uhubuild/work/compile/build' /usr/bin/cmake -E cmake_progress_report /var/uhubuild/work/compile/build/CMakeFiles [ 98%] Generating checkXML.1 cd /var/uhubuild/work/compile/build/doc/checkXML && ../../bin/meinproc4.shell --stylesheet /var/uhubuild/work/compile/kdoctools/docbook/xsl/manpages/docbook.xsl --check --srcdir=/var/uhubuild/work/compile/kdoctools/ /var/uhubuild/work/compile/doc/checkXML/man-checkXML.1.docbook Writing checkXML.1 for refentry
Also, since you mentioned docbook, I looked it up in our system and, well, here are our kdelibs build-depends: acl-dev automoc4 avahi-dev cmake enchant-dev jasper-dev krb5-dev libungif-dev libxslt-dev openexr-dev pcre-dev phonon-dev qt4-dev soprano-dev strigi-dev xz And the reverse depends (i.e. who depends on it) of everything that has the word docbook in it: /uhubuild/SRC/dev/kdelibs# for i in `apt-cache search docbook | cut -d" " -f1`; do apt-cache rdepends $i; echo; done docbook2man Reverse Depends: lxde docbook-dtds Reverse Depends: xmlto docbook-xsl Reverse Depends: xmlto gtk-doc Reverse Depends: lxde Reverse Depends: And also nothing depends on xmlto. Thus, from what I can see, there's no relation here between kdelibs and any of our docbook* packages. Neither of these packages is pulled into the build environment, apparently, so their versions shouldn't matter.
It doesn’t stop on man-kded4.8.docbook, but it does on man-kdeinit4.8.docbook for example.
*** Bug 226091 has been marked as a duplicate of this bug. ***
Anyone interested in this, please see the attachment at the duplicate bug (226091).
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
KDE v4 is obsolete, so I'll close it as such. I'm fairly sure this got otherwise solved (as we did manage to build KDE 4.4 and beyond), but I can't remember what the root cause was for the hang. Knowing software, I'd guess the N+3rd layer somewhere deep in the stack :)