Pulling GTest and compiling locally did not work as expected. The original intention had been to resolve inconsistencies with how OS packages install GTest, leading to problems with building the tests on some systems like CentOS 6.
It seems that these inconsistencies were not caused strictly by some packaging problem, but rather by CMake being unable to correctly detect linking flags for libgtest.
The problems as follows:
- C++ is used to compile tests with GTest; CMake was incorrectly configured on how to call C++ in these instances due to a project level setting 1. This means that pthread links correctly in the C case but doesn't in the C++ case. CMake bug? GCC version dependent?
- CMake's FindGTest module determines if GTest should be linked with pthread based on what the parent projects settings is. This in general is fine, unless you have the above inconsistency. If some OS packages compile GTest without thread support, then there is never a problem. On CentOS 6 though they do compile it with pthreads, ergo problem. For C++ compilation the pthread flags are not propagated by CMake and linking therefore fails.
Trying to resolve these problems by download/compiling GTest locally was the wrong way of doing this.
The masterrun machines have a custom install of GTest with everything correctly setup and working! We do not compiled GTest with pthread, there is also no real benefit for doing this at the moment. We revert the GTest downloading/compiling and go back to using system GTest.