[Bug 280396] Mk/Uses/cmake.mk: Disallow USE_CSTD and USE_CXXSTD

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280396

--- Comment #25 from Matthias Andree <mandree at FreeBSD.org> ---
(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 at .  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.