39

Google's C++ Test Framework has two output libraries: one is gtest.lib and the other one is gtest_main.lib. According to Nik Reiman's answer on how to setup gtest with Visual Studio, we should link to gtest_main.lib but I'm linking to gtest.lib and the sample test cases that I have are running fine.

What's the difference between the two libraries and does it matter which one I link to?

Community
  • 1
  • 1
Kiril
  • 39,672
  • 31
  • 167
  • 226

3 Answers3

37

the only reasonable difference is that gtest_main.lib provides a default implementation of a test application entry point (i.e. main function):

Citation from Getting started with Google C++ Testing Framework:

"[...] maybe you think that writing all those main() functions is too much work? We agree with you completely and that's why Google Test provides a basic implementation of main(). If it fits your needs, then just link your test with gtest_main library and you are good to go."

If you want to write your main function yourself - you should link with gtest.lib.

Macke
  • 24,812
  • 7
  • 82
  • 118
Andrey
  • 4,216
  • 1
  • 23
  • 31
  • Copy/paste of `main()` is more work than setting up your project to link gtest_main.lib? I'd argue that it's not. Anyway, thanks for the quote. I was wondering why it was done this way. – chappjc May 06 '14 at 17:43
  • 8
    gtest_main is **not** an alternative to gtest. You need to link with gtest if you want to use the library either way. If you also want the default main implementation, also link with gtest_main. – Tamás Szelei Jan 09 '15 at 10:11
  • 1
    I'm having a problem setting up gtest to work on my solution. I've added a new project (copied source from one of the samples), added relevant include and linking directories, and specified gtest.lib and gtest_main.lib to link against. If I build my project as a .dll, the tests aren't discovered, and if I build as .exe I have no entry point defined. How do I set-up my project to use gtest_main main() function as the entry point? – Zepee Nov 13 '15 at 17:48
  • 1
    @TamásSzelei - that doesn't seem to be the case at least for the `make` build in release 1.8 (most recent release as of today). The corresponding dependencies are `gtest-all.o gtest_main.o` and `gtest-all.o` for `gtest_main` and `gtest` respectively, so `gtest_main` is a superset of `gtest` and includes all the gtest functionality. – BeeOnRope Feb 08 '17 at 22:44
  • @BeeOnRope I don't think that this changed, although I used the cmake build. In the current master commit gtest_main is not a superset of gtest: https://github.com/google/googletest/blob/master/googletest/CMakeLists.txt#L91 – Tamás Szelei Feb 12 '17 at 15:21
  • Interesting. It seems that the `cmake` and `make` builds are simply inconsistent. The `Makefile` is [here](https://github.com/google/googletest/blob/master/googletest/make/Makefile) and clearly links in `gtest-all.o` for `gtest.a`. Since `cmake` seems to be the recommended way to build going forward, I would assume that the most likely intention is that you gtest_main **not** include the rest of the code, as you mentioned. @TamásSzelei – BeeOnRope Feb 12 '17 at 16:56
  • @TamásSzelei - it was confusing enough I wrote an answer about it. I think that googletest has unnecessarily confused things, but the below should fully cover it. – BeeOnRope Feb 12 '17 at 17:45
  • @BeeOnRope wow, good find. I think this is worth reporting as a bug. – Tamás Szelei Feb 13 '17 at 08:39
  • 1
    @TamásSzelei, filed: https://github.com/google/googletest/issues/1015 - although with 354 open issues I don't have too much hope for a speedy resolution. – BeeOnRope Feb 14 '17 at 19:21
12

In fact, the various build methods available for googletest don't build the libraries consistently. At least this part is consistent though:

gtest

The gtest library (variously called gtest.a, gtest.so, gtest.lib or libgtest.a, etc, depending on your platform and whether you are using the shared library) contains the object code for the gtest framework, including everything that tests need. Basically it implements everything you can use from gtest/gest.h. It does not include a main() method.

gtest_main

It includes a trivial main method that will launch the registered tests, something like this (as of 1.8):

GTEST_API_ int main(int argc, char **argv) {
  printf("Running main() from gtest_main.cc\n");
  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

Now the inconsistent part is that gtest_main sometimes also includes everything from gtest, so that you only need to link against either gtest (if you want to write your own main() method) or gtest_main (if you want the use the canned main method above). This is the case, for example, if you use the Makefile build included in googletest/make:

gtest.a : gtest-all.o
    $(AR) $(ARFLAGS) $@ $^

gtest_main.a : gtest-all.o gtest_main.o
    $(AR) $(ARFLAGS) $@ $^

Clearly, gtest_main.a includes everything that gtest.a does, plus the gtest-main.o object which includes the main function.

With the CMake build, however, the situation is different, at least for some build artifacts. For example, for the main libraries we have:

cxx_library(gtest "${cxx_strict}" src/gtest-all.cc)
cxx_library(gtest_main "${cxx_strict}" src/gtest_main.cc)
target_link_libraries(gtest_main gtest)

Here, gtest_main only contains the main function and nothing much else1. The target_link_libraries line tells anything else using this CMake build that if you link gtest_main you should also link gtest, so in the rest of the file it is common to see things linked only against gtest_main. Indeed, the documentation earlier in the CMakeLists.txt file makes this explicit:

# Defines the gtest & gtest_main libraries.  User tests should link
# with one of them.

Note the "with one one them" part. What they really mean is that if you are building with this same CMake system you can do that, but at the actual link level you need both libtest.a and libgtest_main.a or else you won't pull in what you need to write a test.


1 Indeed, with CMake libgtest.a ends up at 1,755,216 bytes, and libgtest_main.a is only a paltry 3,836 bytes. With the ../make/Makefile build, those figures are 3,365,240 and 3,398,356 respectively. Evidently there are differences beyond the files included that blow up the size of the Makefile version.

BeeOnRope
  • 60,350
  • 16
  • 207
  • 386
-4

You will need to link gtest.lib to your project with the unit tests.

kiriloff
  • 25,609
  • 37
  • 148
  • 229