gtest pthread failures

[mbanck]

On Debian unstable, gtest seems to require pthreads, I get the following linking failures:

/usr/bin/ld: [ 81%] Linking CXX executable math_test
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/units/mathutil && /usr/bin/cmake -E cmake_link_script CMakeFiles/math_test.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro CMakeFiles/math_test.dir/math.cpp.o -o math_test  ../../../src/libecpint.a /usr/lib/x86_64-linux-gnu/libgtest.a ../../../external/Faddeeva/libFaddeeva.a /usr/lib/x86_64-linux-gnu/libpugixml.so
/usr/lib/x86_64-linux-gnu/libgtest.a(gtest-all.cc.o): in function `testing::internal::ThreadLocal<std::vector<testing::internal::TraceInfo, std::allocator<testing::internal::TraceInfo> > >::~ThreadLocal()':
./obj-x86_64-linux-gnu/googletest/./googletest/include/gtest/internal/gtest-port.h:1750: undefined reference to `pthread_getspecific'

The pkg-config files for gtest mention -lpthread.

This patch makes it link, I'm not sure whether there's some better way to figure out how gtest is built/needs pthread (I guess this is a band-aid that won't work for everybody):

--- ./external/ImportGTest.cmake.orig   2020-10-13 21:19:43.403659158 +0200
+++ ./external/ImportGTest.cmake        2020-10-13 21:19:53.967714651 +0200
@@ -39,5 +39,5 @@
   message("Found googletest")
   add_library(gtest INTERFACE)
   target_include_directories(gtest INTERFACE ${GTEST_INCLUDE_DIR})
-  target_link_libraries(gtest INTERFACE ${GTEST_LIBRARY})
+  target_link_libraries(gtest INTERFACE ${GTEST_LIBRARY} pthread)
 endif()

[robashaw]

Thanks for reporting this. Searching around, this seems to be a known issue with googletest on certain Linux distros. I will look into whether there is a sensible way to handle it, or if not I will at the very least add a note to the docs.

The problem with your patch is that it would break things for other systems, as you've guessed - but it is certainly a sensible temporary workaround.

Just for reference, can you tell me what compiler (+ version) you're using?

[benczaja]

Hi, I am also experiencing this problem building on Centos 8 with GCC-10.3.0. I was able to build fine on a Debian 10 with the same compiler. Are there any updates with this issue?

[mbanck]

I just checked, and it is still an issue with latest libecpint (1.0.7) on Debian unstable, the C++ compiler is:
c++ (Debian 11.2.0-13) 11.2.0
The libgtest-dev GTest Debian package version is 1.11.0-3

[robashaw]

I will have another look, but this is very much outside of my expertise.

If tests aren't needed, you can build without GTest with the cmake option LIBECPINT_BUILD_TESTS=OFF and this won't affect the functionality.

[mbanck]

I noticed GTestConfig.cmake has this code:

include(CMakeFindDependencyMacro)
if (ON)
  set(THREADS_PREFER_PTHREAD_FLAG )
  find_dependency(Threads)
endif()

So I guess this should be picked up by external/ImportGTest.cmake or somewhere.