Including through CMake's FetchContent breaks gtest_discover_tests on Windows

[thierryseegers]

Describe the bug
When including json-c in one's CMakeLists.txt through FetchContent_* functions, a conflict occurs that makes gtest_discover_tests misbehave. I've reproduced the error with both MSVC (VS2019) and MSYS+mingw (g++ 10.3) combinations of platform/toolchain.

Steps To Reproduce
I reduced the error to its simplest expressible form and attached it:
libjsonc-gtest-conflict.zip

This is how the error manifests itself:

1. I use FetchContent to fetch the latest googletest and use it with a test executable. The function gtest_discover_tests is used. This is textbook. Everything works fine, configuration and build.
2. I add the latest libjson-c to the CMakelists.txt using the same mechanism of FetchContent_Declare and FetchContent_MakeAvailable.
3. Configuration works fine but when it comes to building, after successfully building the test executable this is observed:

CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/GoogleTestAddTests.cmake:77 (message):
Error running test executable.
Path: '[...]/build/win-msvc/Debug/tests.exe'
Result: Exit code 0xc0000135

Please note that json-c is not used or referred to at all after having been made available. It is the mere addition of it with FetchContent_MakeAvailable in the build scripts that produces this error! If I comment out FetchContent_MakeAvailable(libjson-c) the problem goes away. If I comment out the call gtest_discover_tests the problem goes away. Because FetchContent_MakeAvailable is essentially a glorified add_subdirectory, it appears that there's something in json-c's CMakeLists.txt that influences GoogleTest's CMakeLists.txt. This feels even more obviated by the fact that reversing the order of FetchContent_MakeAvailable and "including" gtest before json-c appears to work around this issue.

Version and Platform

• json-c version: json-c-0.15
• OS: Windows 10, MSYS
• Cmake: 3.21.1

[hawicz]

Sounds like the tests.exe executable is being linked against json-c, but when run the system can't find the dll (0xc0000135 appears to be "STATUS_DLL_NOT_FOUND"). Having the library get linked in seems like something reasonable to me, but I'm not at all familiar with what googletest is meant to do here, and in my environment trying to build fails with other error (perhaps due to old g++).
If you can figure out what the problematic bit is, I'll be happy to apply a fix, but I'm not going to be able to help much figuring things out.

[thierryseegers]

@hawicz Here's the thing though, I really don't think it's getting linked against json-c. It really shouldn't be anyway because there's nothing in the CMakeLists.txt that requests it, e.g. target_link_libraries(tests json-c). I quickly confirmed it with Dependencies.

I'll be honest, analyzing the buggy interactions of two gnarly CMakeLists.txt I didn't write is not exactly my idea of a fun Sunday afternoon... 😆 I filed this bug with the faint hopes that it would ring a bell or that someone would have the inkling of a clue for how to debug it. I know I can make CMake more verbose but I wouldn't know what to search for in this case. The only "obvious" thing to first look at would be whatever command is in json-c's CMakeLists.txt that is "global" in nature as opposed to target-oriented that would have repercussion in other projects included afterwards.

It's just unfortunate that consuming a CMake-based projects can be done in so many different ways and writing it perfectly for all cases is nigh impossible...