NFD » ndn-cxx

This is not really a bug report, it's just to document the problem in case others run into it.

Long story short, there was a major C++11 ABI break in GCC 5's libstdc++, and in the "new ABI" configuration (the default in Ubuntu 15.10 and in the upcoming Fedora release) GCC now adds a special tag [abi:cxx11] to the mangled name of some symbols, e.g.:

$ nm -CD /usr/lib/libcrypto++.so | grep -F DEFAULT_CHANNEL
00000000006158c0 B CryptoPP::DEFAULT_CHANNEL[abi:cxx11]

However clang does not support GCC's abi_tag so it still generates the "old" mangled names. This leads to linking failures when a program (or library) built with clang tries to link against a library built with GCC 5, if the program needs one or more symbols from the library that are affected by the ABI break (and therefore by the new mangling), because the linker will look for the untagged symbol that doesn't exist in the "new ABI" library.

In the specific case of ndn-cxx, this problem can already be observed at the configure stage. Linking against libcrypto++ fails with:

err: test.cpp.1.o: In function `main':
/home/davide/ndn-cxx/build/.conf_check_e6476207f97688496730921c1b3d0bd5/testbuild/../test.cpp:12: undefined reference to `CryptoPP::DEFAULT_CHANNEL'
/home/davide/ndn-cxx/build/.conf_check_e6476207f97688496730921c1b3d0bd5/testbuild/../test.cpp:12: undefined reference to `CryptoPP::DEFAULT_CHANNEL'
/home/davide/ndn-cxx/build/.conf_check_e6476207f97688496730921c1b3d0bd5/testbuild/../test.cpp:14: undefined reference to `CryptoPP::DEFAULT_CHANNEL'
/home/davide/ndn-cxx/build/.conf_check_e6476207f97688496730921c1b3d0bd5/testbuild/../test.cpp:14: undefined reference to `CryptoPP::DEFAULT_CHANNEL'
test.cpp.1.o: In function `CryptoPP::SourceTemplate<CryptoPP::StringStore>::Pump2(unsigned long long&, bool)':
/usr/include/cryptopp/filters.h:763: undefined reference to `CryptoPP::DEFAULT_CHANNEL'
test.cpp.1.o:/usr/include/cryptopp/filters.h:765: more undefined references to `CryptoPP::DEFAULT_CHANNEL' follow
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This is a very sad situation but unfortunately there's not much we can do.

References:

https://llvm.org/bugs/show_bug.cgi?id=23529

http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791112