Comment by derefr

It's the stuff you find in LLVM's libc++abi (https://libcxxabi.llvm.org/spec.html) or GCC's libsupc++ (https://wiki.osdev.org/Libsupcxx).

• These libraries provide the set of functions that compiled C++ code expects to call into to implement syntax-level features, like exception unwinding, destructors, and runtime type inference (RTTI).

• These libraries also define the C++ equivalents of the C runtime's _init and _fini functions. The C++ versions do a lot more: they set up the exception unwinder (copying and fixing-up .data-section DWARF tables into exception-unwind lookup tables for the active .text-section address-space mappings); they register global destructors; they register signal handlers (and per-thread-create handlers to re-register those signal handlers), to make the particular signal received by https://man7.org/linux/man-pages/man3/pthread_cancel.3.html trigger exception-unwind and destructors; ...etc.

Usually, a C++ runtime support library gets static-linked into a C++ stdlib; and then a program implicitly receives linkage to the C++ runtime support library as part of statically or dynamically linking to the C++ stdlib.

However, if you want a "minimal" C++ binary — and you never use anything in `std` (maybe because you're just using C++ to be able to write "C with templates") — then you can just link only the C++ runtime support library itself.

(And yes, all of these C++ syntax features that require runtime support are technically optional. You can just `-fno-exceptions -fno-rtti -ffreestanding -fno-asynchronous-unwind-tables -fno-unwind-tables`, and then never link a C++ runtime support library at all — if you're willing to only use placement `new` and never use destructors or exceptions or RTTI. But at that point you're not exactly writing C++; you're writing an "embedded profile" of C++, akin to targeting the Java SE Embedded platform. Which makes sense if you're coding e.g. an RTOS kernel; but goes against the much of the point if you're just writing e.g. the "native loadable module" for an HLL ecosystem package. Now your code can't depend on arbitrary third-party C++ code [because there isn't an "embedded C++" ecosystem, only a regular C++ ecosystem]; you can't find any FOSS contributors willing to help you maintain it [because 99% of people only know C++, not "embedded C++"]; and so on.)