# FindGTest always links "Threads::Threads" to target "GTest::GTest"

**URL:** https://discourse.cmake.org/t/findgtest-always-links-threads-threads-to-target-gtest-gtest/8703
**Category:** Development
**Created:** [August 9, 2023, 9:14am UTC](https://discourse.cmake.org/t/findgtest-always-links-threads-threads-to-target-gtest-gtest/8703 "2023-08-09T09:14:50Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![PiJ82](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pij82/32/3698_2.png) [@PiJ82](https://discourse.cmake.org/u/PiJ82)
#### Post date: [August 9, 2023, 9:14am UTC](https://discourse.cmake.org/t/findgtest-always-links-threads-threads-to-target-gtest-gtest/8703/1 "2023-08-09T09:14:50Z")

</div>

Hey everyone,

in case `find_package(GTest)` successfully imports the `GTest::GTest` target via the _FindGTest.cmake_ module (and no matching gtest config script could be found), `Threads::Threads` is always added as interface link library to the imported gtest target (see [here](https://github.com/Kitware/CMake/blob/v3.27.1/Modules/FindGTest.cmake#L283)).  
However, this may not always be the correct case, because gtest can be built without pthreads support (see [cmake option gtest\_disable\_pthreads](https://github.com/google/googletest/blob/v1.14.0/googletest/CMakeLists.txt#L22)).

While I understand the reasoning behind the decision to always link against `Threads::Threads` - how would the find script know whether gtest was built with thread support or not, so it doesn’t hurt to always link it - it may hide subtle bugs in the code under test:  
In my case, one component forgot to add `Threads::Threads` as public link dependency for the `INSTALL_INTERFACE` and only populated it via the `BUILD_INTERFACE`. By implicitly linking the `Threads::Threads` target to the `GTest::GTest` target, `-lpthread` was always appended by the linker, hiding the missing dependency in the test executables and leading to undefined references in customer code.

I’m not quite sure whether this can be addressed in any way, but it would be nice to have a way to disable this behavior. Maybe by adding a new CMake variable to affect that behavior (e.g. `GTEST_DISABLE_PTHREADS=ON|OFF` with a default value `OFF` for backwards compatibility).

If not, maybe someone has a hint how to disable the implicit link dependency?

Thanks,  
René.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 9, 2023, 11:32am UTC](https://discourse.cmake.org/t/findgtest-always-links-threads-threads-to-target-gtest-gtest/8703/2 "2023-08-09T11:32:07Z")

</div>

`FindGTest` would need to learn how to inspect whether it is needed or it could be hinted with such a variable, yes.

---

<div class="post-metadata">

### Author: ![PiJ82](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pij82/32/3698_2.png) [@PiJ82](https://discourse.cmake.org/u/PiJ82)
#### Post date: [August 9, 2023, 2:01pm UTC](https://discourse.cmake.org/t/findgtest-always-links-threads-threads-to-target-gtest-gtest/8703/3 "2023-08-09T14:01:49Z")

</div>

Any idea how `FindGTest` could learn that? It seems like the cleaner solution, but wouldn’t be easy to implement I guess.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [August 9, 2023, 4:01pm UTC](https://discourse.cmake.org/t/findgtest-always-links-threads-threads-to-target-gtest-gtest/8703/4 "2023-08-09T16:01:25Z")

</div>

Is there some way to tell if `libgtest` needs `pthreads`? If so, you can do that detection and conditionally add the `Threads::Threads` dependency.