When building the Google Test framework, the --enable/disable-pthreads configure options, controlled by the threads USE-flag in the ebuild, cause -DGTEST_HAS_PTHREAD=1/0 respectively to be added to the compilation flags. This in turn adjusts the definitions of various thread-related classes and functions in the header files - without threads they are either removed or replaced with dummy implementations. However, these -D flags are not returned by the gtest-config program, so applications using the library will get the threaded versions by default. This causes problems in particular for the mutex variable testing::internal::g_linked_ptr_mutex, which is defined in the shared library and referenced by some of the macro/template code used by clients of the library. If the library was built with threads disabled, it will be a one-byte placeholder, but clients will try to access it as a full mutex, which can cause errors such as assertions in the pthreads library as it will not contain a correctly initialised pthreads mutex. Upstream is probably not interested in fixing gtest-config as they discourage installing the library system-wide (see ¹ and ² for example), preferring applications to bundle their own copy, even though bundling is frowned upon by most Linux distributions. Therefore, the simplest fix it probably to just hard-enable the threads option (I don't see any particular reason for users to want to disable it). I tried to come up with a minimal test case but couldn't, I suspect because the memory the threads library was trying to use just happened to look like a valid mutex in that particular program. [1] http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog [2] http://groups.google.com/group/googletestframework/browse_thread/thread/79d30a96bbeab165/af5e1b9970dce97c?#af5e1b9970dce97c
This has been around for long enough. Fixed in 1.6.0-r1.
Whoops, missed the resolved button.