Unit tests don't link on Windows w/ MSVC2017 CMake build

[louis-langholtz]

Migrated here from my Box2D fork issue #24.

At last check, the project's library and the unit tests all build on Windows. But the unit tests aren't linking with everything it needs.

Mismatch of link options. Part built with MDd and other with MTd if memory serves me.

Incidentally, I've updated the MSVS solution and project files and gotten the Testbed and its dependents to all build and link and run under MS VS2017.

[louis-langholtz]

Update: On retrying the Windows build of the unit tests, I wound up upgrading CMake to 3.9.0...

Somehow I got a message about PythonInterp not being installed. That was odd since I don't recall seeing Python come up before as a pre-req. In any case, after installing from python.org I realized that its default install wasn't findable by CMake. Selecting the custom install option for python and selecting the install-for-all-users option, got me past the python error.

Selected only the static CMake options, I get an error about unresolved external symbol g_linked_ptr_mutex. Selecting the shared library options seem to get a slew of mismatched link options that may well be what I saw before.

[NauticalMile64]

I'm also getting this linker error with VS 2017 (build generated with CMake 3.9.0, re-installed today). Just to clarify were getting the same thing, I have:

LNK2019 unresolved external symbol "class testing::internal::Mutex testing::internal::g_linked_ptr_mutex" (?g_linked_ptr_mutex@internal@testing@@3VMutex@12@A) referenced in function "public: virtual void __cdecl testing::internal::ParameterizedTestCaseInfo::RegisterTests(void)" (?RegisterTests@?$ParameterizedTestCaseInfo@VVerticalStackTest@@@internal@testing@@UEAAXXZ) UnitTests C:\path\to\PlayRho\Build\cmake-build\UnitTests\World.obj 1

I haven't seen any messages about PythonInterp not being installed, but I do have a working installation of Python 3.6.1 at the default location for other projects, so it could be finding that and using it behind the scene.

I also noticed that the 4 other unit tests do not compile in the release configuration (submitting those issues next). Perhaps there is a chance this will disappear if we solve those first?

[louis-langholtz]

@NauticalMile64 Do you know anything about the status of this issue by chance? I was imagining (happily/keenly) that you'd been interested in moving this issue forward. Is this an issue you've fixed or are interested in working on?

[louis-langholtz]

Incidentally, I've also been thinking of adding CMake builds to the AppVeyor build matrix. Not sure where that fits in but seems related to me at this moment to this issue.

[NauticalMile64]

@louis-langholtz As best as I can tell it's an issue with google/googletest, and not PlayRho. I tried looking into it a little, but it seems way over my head. :( The issue to watch is google/googletest#292. I'll try commenting and calling out some maintainers by name to draw attention to it.

The linker error appears whether the project is built with CMake or from the provided VS solution.

[NauticalMile64]

There are a few other linker errors which I'll submit issues for and resolve in the next day or two, but this is the showstopping issue right now for testing with VS.

[emptyVoid]

I saw this issue referenced in google/googletest#292, and decided to try to help.
I was able to build UnitTests on Windows with VS2017 in two different ways:

1. Enabling BUILD_SHARED_LIBS via CMake, and adding GTEST_LINKED_AS_SHARED_LIBRARY to the preprocessor definitions via Project Properties in VS (the latter should be doable with add_definitions CMake function).
2. Enabling gtest_force_shared_crt via CMake (with BUILD_SHARED_LIBS disabled).

[louis-langholtz]

@emptyVoid Thank you for helping out with this!

Of the two ways you got UnitTests to build, is there one that you'd suggest over the other? One that works better in terms of changing a CMakeLists.txt file? If so, what instructions exactly would you recommend using/adding/changing?

I'm gonna look into getting things working using either of your suggestions but I'd be psyched to get your input on these questions!

[louis-langholtz]

I've been able to build and run the unit tests using the second method by invoking cmake in a git bash shell as:

cmake -G"Visual Studio 15 2017" -DPLAYRHO_BUILD_UNIT_TESTS=ON  -Dgtest_force_shared_crt=ON

Unfortunately in the debug build I made, the tests assert early on in the AABB2D.ComparisonOperators unit test. The assert has nothing to do with googletest though. Looking into the why of the assert and how to fix.

[louis-langholtz]

Debug mode builds and runs now to completion. 20 of the tests fail. All but 3 of the failed tests are byte size tests. The non size related tests that fail are: Fixed32.GetTypeName, Math.LengthFasterThanHypot, and World.TilesComesToRest. None of these failures are significant.

Release mode builds and runs now to completion also. 7 of the release build unit tests fail. 6 of these are byte size tests. The other is the World.TilesComesToRest test. None of these failures are significant either.

I'm gonna look into changing the CMake configuration so that it automatically enables gtest_force_shared_crt if it sees that the enable building of unit tests is selected.

[louis-langholtz]

At this point AppVeyor is building the library, the HelloWorld application, and the UnitTests application all via cmake for static builds. Getting shared library builds working for Windows is something I'd also like to have but I'm gonna call this issue closed as is now and open a new one for cmake building for windows using shared library.