Platform: AMD Bulldozer (yes, that old)
OS: Gentoo X86_64
gcc: 11.3.0 (Gentoo 11.3.0-p4)
clang: 13.0.1
Xerces-C: v3.2.3
Xalan-C: v1.12.0
Xerces-C was installed via Gentoo ebuild. No errors or warnings were
encountered during install.
Xalan-C was cloned from github repository. Foll
Hi Scott,
Hard to diagnose without more information. Can you build with verbose logging,
so we can see what ninja is waiting on? Does "ps" or "pstree" show any
children which have become stuck? Does it happen if you build with no
parallelisation?
It's possible there is a broken rule being e
Roger,
From what I have encountered in the past, Ninja appears notorious for
rushing to compile leaving "holes", gaps or otherwise in its wake on
occasion. It's easy to blame Ninja but it is also possible there is
misconfiguration involved. I'm not personally a fan of Ninja but I
haven't made
Hi Scott,
This isn't ninja at fault. Ninja itself should have a complete dependency
graph, so its behaviour should not be materially different than traditional
make--but it's usually much faster due to the lack of pattern rules etc since
they have to be expanded up front at generation time (by
I had been careful to document and follow the same steps in ensuring I
was not imagining things. The problem of testing hanging right at the
end was persistent even after cleaning/resetting repository and
switching between CMake build methods (i.e. "Unix Makefiles" or Ninja).
For some reason, C
