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

Question

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.

@MatthieuBrucher no, it means "some low-level features such as exception objects, rtti and memory allocation" not `std::set` and `std::string`. — Jonathan Wakely, Nov 23 '18 at 11:24
@rubenvb it's not part of the mangled name, but is part of the type. But that's irrelevant here. The problem is much less subtle than that. — Jonathan Wakely, Nov 23 '18 at 11:25
Did you maybe read the goal as "except for" instead of just "for"? You disable RTTI and exceptions and worry about `std::allocator` as if you think that exception objects, rtti and memory allocation are the things that are *not* compatible, when in fact they are the **only things** that are. — Sebastian Redl, Nov 23 '18 at 11:29

score 4 · Accepted Answer · answered Nov 23 '18 at 11:23

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.

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

1 Answers1