Search code examples
c++libstdc++abilibc++object-files

When/why are libstdc++ and libc++ symbols incompatible?


Setup:

test.cpp

#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>& allowed_options) {}

include.cpp

#include <set>
#include <string>

void common_config_file_iterator(const std::set<std::string>&) noexcept;

int main() {
    std::set<std::string> set;
    common_config_file_iterator(set);
    return 0;
}

test.sh

clang++-7 test.cpp -c -O3 -fno-rtti -fno-exceptions -o test.o
g++-8 test.o include.cpp -O3 -fno-rtti -fno-exceptions -o test

Output:

Undefined symbols for architecture x86_64:
  "common_config_file_iterator(std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)", referenced from:
      _main in ccWoGgrX.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

So I did nm -g test.o:

0000000000000000 T __Z27common_config_file_iteratorRKNSt3__13setINS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_4lessIS6_EENS4_IS6_EEEE

According to demangler.com, it means:

common_config_file_iterator(std::__1::set<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<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> > > > const&)

Libc++ says:

[Features and Goals:] ABI compatibility with gcc's libstdc++ for some low-level features such as exception objects, rtti and memory allocation.

So, is the problem std::allocator<char>?

Note that I use the macOS assembler.

Curiosity caused by this issue and boost/program-options.


Solution

  • So, is the problem std::allocator<char>?

    What? No. It's everything in your example.

    The doc you quoted clearly says the goal is compatibility for "low-level features such as exception objects, rtti and memory allocation".

    std::set and std::string are not "low-level features such as exception objects, rtti and memory allocation". They are very definitely not compatible between libc++ and libstdc++, which are completely different libraries with completely different implementations.

    The compatible pieces are things like std::type_info and std::exception (and the derived exception types in <stdexcept>) because those are part of the basic language runtime. Anything above that, such as containers, strings, algorithms, I/O, locales etc. is not compatible.