Gtest C++17

[Florio Bessinger]

Googletestgtest) seems to be an immensely popular unit test framework and I'd like to learn how to build it stand-alone on the g++ compiler, simply and easily, so I can test small libraries and one-off files with it.

I know I can do the following to use cmake, but it doesn't give me the level of granular control I desire, and it still doesn't answer the mystical question of "how do I use these .a static library files when done?".

If you're on Windows, you can run Bash and gcc and g++ build commands inside an MSYS2 terminal. See my full setup and installation instructions here: Installing & setting up MSYS2 from scratch, including adding all 7 profiles to Windows Terminal. git commands, however, should still be run inside the Git Bash terminal in Windows which comes with Git for Windows.

Can you post the verbose build log for both? Use cmake --build --verbose for building both. You can also post the output of otool -L gtestcrash_test. There must be some difference in how they are being compiled.

Also, the xcode one uses gnu++17. I guess if I had access to the machine I would run the command lines by hand since it is one file and two compile lines (one to build the .o and one to link the main). Then when I would remove flags until I find the one that is causing the trouble. Also you could try running in gdb to see where it crashes. My guess is that one of the flags in the xcode one is pulling in a different system library or ABI that is not compatible with the gtest you are linking against.

Thank you for the feedback. I guess I can try to remove options and figure out where the problem is, but clearly the problem is not in my code, nor in the way I use CMake. So in your opinion, who should be in charge of this issue? Is it GoogleTest? Is it CMake?

Well, I actually have not seen your CMakeLists.txt code. It is possible the issue is there. My guess is that it has something to do with the gtest you are using. Is that compiled? Where did it come from?

The CMakeLists.txt is included in my original post. GoogleTest is a clone of the github repo (GitHub - google/googletest: GoogleTest - Google Testing and Mocking Framework). Besides the gtest_force_shared_crt option, which makes no difference if you remove it, there is nothing I do on my side.

There is a fair bit of documentation available on the project site, but sometimes you just want to get a feel for something before committing yourself to it. This posting should help you do that, but if you want more, the project has good documentation. In my quest for documentation I noticed several guides, a FAQ, a Wiki and a mailing list. In other words, there are good sources of information available if you choose to dive in.

If you are coming from a Java world then this may be where you hit your first snag. It may be a bit different from what you have grown accustomed to with Eclipse, JUnit and all, but you will have to build the unit test binaries from the downloaded C++ source code. Yes, you will actually have to compile and build the GTest libraries yourself, but before you lose heart, let me add that it comes with project files for many popular C++ IDEs, Visual Studio being one of them (older version). In the msvc/ folder of the download you will find two Visual Studio solution files which VS 2008 will ask you to upgrade when you open them.

In any case, if you plan on using both Debug and Release configurations in your own project then you should remember to also build the GTest solution for both Debug and Release configurations. Among other things, the Release configuration will build two files, gtest.lib and gtest_main.lib, and similarly, the Debug configuration will also build two files, namely gtestd.lib and gtest_maind.lib (notice the extra -d- character in the file names).

An alternate command-string for the post-build event:

start cmd.exe /k $(TARGETPATH)

Launches a CMD window with the test executable, rather than dumping the output into the window. If for no other reason, to see the results in green or red. You do have to close the cmd window to complete the build, tho, which could be annoying.

Probably poorly worded - what I was trying to convey is that if we want to use a C++17 feature that's really impactful on the syntax/readability we should probably consider recommending ways to use it in the coding standards, similar to our guidelines on using for() loops ( -range-based-for-loops-wherever-possible) or the auto keyword ( -auto-type-deduction-to-make-code-more-readable).

Since we can already test this with a current flag maybe we should just post to discourse that bot-owners can test it and a date when this will be merged. But I don't expect this to be a big problem, when we merged the soft error earlier this year - it only broke one bot which was out of date.

I don't think the standard library can be called a vendor-specific extension, and so I think this still could/should be made clearer (even though the status links below would show upon inspection that there's no full support yet, but that's a bit too tucked away I feel).

I don't think so : the migration to C++11 was done the same way, piecewise by making sure that when we start using a new feature (core or stdlib) it actually works on the stated minimum version of the toolchains we support.

I wasn't aware of that - but I think it's expected since the check in RWMutex checks for the C++ standard and doesn't care about the deployment target for macOS. It seems pretty easy to change, but I wonder if that matters? 10.12 was released in 2016 so it's pretty old and this wouldn't affect most users of LLVM.

Thanks! We took this opportunity to bump our clang deployment target from 10.7 to 10.12 (which makes a few other minor things easier too), so we don't need this change any more. But it's a good change anyways :)

This seems to have been more disruptive than expected, since an existing CMakeCache.txt can make LLVM compile in previous C++14 configuration. This seems to make some of the bots fail in a way that makes the patches making use of C++17 features seem at fault.

Switching between BFD ld and gold still fails (although gold fails for a slightly different reason). Superficially it seems that switching to C++17 for some reason might be causing the compiler to emit debug info that these older non-lld linkers cannot understand for some reason?

We are seeing an additional failure on an internal linux bot due to the change to using C++17 by default when using GNU ld:

...

Switching between BFD ld and gold still fails (although gold fails for a slightly different reason). Superficially it seems that switching to C++17 for some reason might be causing the compiler to emit debug info that these older non-lld linkers cannot understand for some reason?

FWIW, that revert was not necessarily due to cmake cache issues (though those issues may exist, I haven't checked). I reverted that change because it broke the build for me locally as well as caused some bots to go red. My local build definitely rebuilt the cache and still failed.

3a8082e126