Googletest: CLANG compiles where GCC fails-CodePudding

Here is a very simple script using gtest (saved in file gt.cpp)

#include<gtest/gtest.h>

double timesTwo(double x){return x*2;}

TEST(testTimesTwo, integerTests){EXPECT_EQ(6, timesTwo(3));}

int main(int argc, char* argv[]){
    testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

The script compiles fine with CLANG (Apple clang version 11.0.3)

clang   -std=c  17 -lgtest gt.cpp -o gt

but fails with GCC (g (GCC) 10.2.0)

g   -std=c  17 -lgtest gt.cpp -o gt

gt.cpp:2:9: fatal error: gtest/gtest.h: No such file or directory
    2 | #include<gtest/gtest.h>
      |

Using the -H option in CLANG, I see the header file is included from /usr/local/include. Also, I can find the libgtest.a file in /usr/local/bin/. So, I did

g   -std=c  17 gt.cpp -o gt -I/usr/local/include/ -L/usr/local/lib/ -lgtest

and got a long list of undefined symbols starting with

Macavity:test remi$ g   -std=c  17  gt.cpp -o gt -I/usr/local/include/ -L/usr/local/lib/ -lgtest
Undefined symbols for architecture x86_64:
  "__ZN7testing8internal9EqFailureEPKcS2_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESA_b", referenced from:
      __ZN7testing8internal18CmpHelperEQFailureIidEENS_15AssertionResultEPKcS4_RKT_RKT0_ in ccrUwUPO.o
  "__ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE4findEcm", referenced from:
      __ZN7testing8internal11SplitStringERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEcPNS1_6vectorIS7_NS5_IS7_EEEE in libgtest.a(gtest-all.cc.o)
      __ZN7testing8internalL21FormatDeathTestOutputERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE in libgtest.a(gtest-all.cc.o)
  "__ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE7compareEmmPKcm", referenced from:

Can you help me figure out why GCC fails to compile here?

CodePudding user response：

Here is this error message passed through a http://demangler.com/

Undefined symbols for architecture x86_64:
  "_testing::internal::EqFailure(char const*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)", referenced from:
      _testing::AssertionResult testing::internal::CmpHelperEQFailure<int, double>(char const*, char const*, int const&, double const&) in ccrUwUPO.o
  "_std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::find(char, unsigned long) const", referenced from:
      _testing::internal::SplitString(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, char, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >*) in libgtest.a(gtest-all.cc.o)
      _testing::internal::FormatDeathTestOutput(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in libgtest.a(gtest-all.cc.o)
  "_std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::compare(unsigned long, unsigned long, char const*, unsigned long) const", referenced from:

Note that second and third error complains that linker can't find implementation of: std::string::find(char, unsigned long) and std::string::compare(unsigned long, unsigned long, char const*, unsigned long) const.

Those are parts of standard C library. Since std::string is template some parts of it are part of library which uses that template, but is some cases it can be part of C runtime.

Now I suspect that you compiled gtest with a clang and try use it when building test with gcc (or vice versa). A bit different implementations of std::string on both compilers lead to divergence in available symbols.

So please make sure that gtest and test application are build with same compiler.

Here is some description of binary compatibility between gcc and clang. There are some hints what problem is, but it is not very formal (maybe I will find better document).