I’m trying to build v3.16.2 from source, using:
./bootstrap --parallel=32 --prefix=~/local -- -DCMAKE_BUILD_TYPE:STRING=Release \
&& make -j32 \
&& make test \
&& make install
But I’m seeing some failed tests…
99% tests passed, 8 tests failed out of 550
Label Time Summary:
Label1 = 0.11 sec*proc (1 test)
Label2 = 0.11 sec*proc (1 test)
Total Test time (real) = 5963.12 sec
The following tests FAILED:
124 - BuildDepends (Failed)
207 - CTestCoverageCollectGCOV (Failed)
450 - RunCMake.CTestResourceAllocation (Timeout)
465 - RunCMake.CommandLine (Failed)
467 - RunCMake.install (Failed)
476 - RunCMake.IfacePaths_INCDIRS (Failed)
503 - RunCMake.CPack_RPM.SUGGESTS (Failed)
508 - RunCMake.CPack_TGZ (Failed)
Errors while running CTest
Platform is linux_x64, gcc 4.8.5
Are the failures expected? If not, how do I go about collecting whatever’s needed to raise an issue on GitHub?
RunCMake.CTestResourceAllocation test timed out because it’s known to take a long time to complete. Increasing the time limit with
ctest should make it pass. The rest of the failures are not expected. To get more verbose information, run
ctest directly (instead of
make test) with the
-V flag (and the
-R flag to filter the failed tests). Since you’re using the bootstrap script, you’ll need to run the built CTest in the
$ bin/ctest --timeout 3000 -V -R "^(BuildDepends|CTestCoverageCollectGCOV|RunCMake\.(CTestResourceAllocation|CommandLine|install|IFacePaths_INCDIRS|CPack_RPM\.SUGGESTS|CPack_TGZ))$"
Also, we prefer to use our own GitLab for issue tracking. If you find an issue, please report it here.
RunCMake.CTestResourceAllocation runs cleanly with the longer timeout. Thank you @kyle.edwards
On the machine I’m building on my home directory is remote (an nfs4 mount), ~/Builds is a symbolic link to a different remote file system (nfs) on a different server. I think some of this might be relevant to some of the other errors. I’ve attached all the verbose logs, and my initial/limited analysis. If people think these should be raised as issues on GitLab let me know and I will create them.
When I get a chance I will try and move to a build path without the symbolic link…
BuildDepends, fails the first time but passes the second. Timestamp granularity/mismatch on nfs file systems?
CTestCoverageCollectGCOV, No idea about this one.
RunCMake.CommandLine, bust paths due to the symbolic link?
RunCMake.install, the 5’th and 6’th components of the regex are swapped in the output (runpath <==> rpath_search).
RunCMake.IFacePaths_INCDIRS, No tests selected to be run?!?
RunCMake.CPack_RPM.SUGGESTS, no idea…
RunCMake.CPack_TGZ, missmatch in the expected paths. The …/…/…/…/…/…/…/…/…/…/ prefix for the path appears in one of the lines in the CTestCoverageCollectGCOV output, maybe both related to the symbolic link?
OK, no attachments… New users can’t do that!!!
Building in a non-symlink’d path with the longer timeout, everything passes except RunCMake.CPack_RPM.SUGGESTS
RunCMake.IFacePaths_INCDIRS still runs nothing, but no-longer counts as a failed test.
This matches my experience. https://gitlab.kitware.com/cmake/cmake/issues/16228 will fix that (whenever I get around to actually finishing it).