https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280396
--- Comment #25 from Matthias Andree <[email protected]> --- (In reply to Daniel Engberg from comment #23) (In reply to Gleb Popov from comment #24) First of all, let me stress a very fundamental and very important difference between C and C++: it's the ABI. Not just exceptions, but everything, name mangling, name spaces of the standard libraries, and whatnot. Again, The important part is **not the language version**, but - for C++ only - the ABI, which isn't standardized (unlike the C ABI). The C++ ABI mostly changes either with compiler version, or with compiler flags that are not specific for a language version, but in our ports tree USUALLY because ports disagree on the Standard C++ version, of which we have two (discounting subversions), libc++ (from the LLVM world) and libstdc++ (from the GNU GCC world). You cannot mix C++ linkage from libc++ (which most ports use) with libstdc++. Accidentally compiling with g++ when the library was compiled with c++ or clang++, will lead to linker errors. So the only useful knobs I see in a port (thanks Daniel) are: - telling the port that it has to use a concrete C++ ABI and standard library, which is far more important; - telling the port to compile to an older language standard such as C++14 or C11 to avoid whatever is the newer default version if none is specified, and here I would say we need to stop adding abandonware where the various downstream life-supports diverge on quality and direction, as we've recently discussed with danfe@. Either a volunteer organizes a revival (possibly of a fork) of an upstream project so that everyone can benefit, or we give some upstream software a decent burial instead and DO NOT package it. Getting something to a newer language level can work to some extent (and with C++17 make the binary actually more efficient and with C++20 better type-checked for good measure) but can also break, as mentioned previously for C23 reinterpreting function declarations from varargs to void, or because newer C++ language standard introduce features (functions) for which a certain upstream project has local functions instead and possibly messed up namespaces (where the worst and most frequent offender is a "using namespace std;" at a wide (say, global) scope). -- You are receiving this mail because: You are the assignee for the bug.
