Undefined reference to google::protobuf::internal::empty_string_[abi:cxx11]

Question

I\'m trying to build simple test application with Protocol Buffers 2.6.1 and GNU GCC 5.1.0 (on Ubuntu 14.10) and I get following errors:

/home/ragnar/cpp-too         


        

Answer 1

I had similar problem as

writeProto.cpp:(.text+0x2a8): undefined reference to `google::protobuf::internal::VerifyVersion(int, int, char const*)'
writeProto.cpp:(.text+0x308): undefined reference to `tutorial::AddressBook::AddressBook()'
writeProto.cpp:(.text+0x3a2): undefined reference to `google::protobuf::Message::ParseFromIstream(std::istream*)'
writeProto.cpp:(.text+0x463): undefined reference to `google::protobuf::Message::SerializeToOstream(std::ostream*) const'
writeProto.cpp:(.text+0x4b4): undefined reference to `google::protobuf::ShutdownProtobufLibrary()'
writeProto.cpp:(.text+0x4c8): undefined reference to `tutorial::AddressBook::~AddressBook()'
writeProto.cpp:(.text+0x515): undefined reference to `tutorial::AddressBook::~AddressBook()'

I wrote this on the command line and now my code is working.

c++ writeProto.cpp addressbook.pb.cc `pkg-config --cflags --libs protobuf`

Answer 2

I suspect this is a C++ ABI issue. The ABI for std::string has changed in GCC 5 (related to C++11 requirements, but it applies even if you aren't using C++11). See:

https://gcc.gnu.org/gcc-5/changes.html#libstdcxx

If libprotobuf was built with GCC 4.x or prior, but your app is built with GCC 5, then you will see problems, because libprotobuf uses std::string in its interface. You have two options:

1. Rebuild libprotobuf with GCC 5 (but now any apps built with GCC 4 won't work with the new version of libprotobuf).
2. Build you app with -D_GLIBCXX_USE_CXX11_ABI=0 as described at the above link. This will force GCC to use the old ABI version.

Answer 3

I had a similar problem, that was caused by the fact that I compiled the protobuf library with GNU's libstdc++, but in the application I was using Clang's libc++, and the two don't work together.

It all became clear once I used ldd <file> to see what shared objects that file depends on.