[gentoo-dev] [RFC] C++ standard in ebuilds

[Guilherme Amadio]

Hi everyone,

I would like to discuss a system-wide way to handle C++ standard setting
in Gentoo. We currently have many packages appending -std=c++XX to their
flags, and it's hard to keep track of which packages use which version
of the standard. This is a problem when packages force dependencies to
use the same version of the standard, or if certain combinations cause
ABI or other breakage (i.e., due to backports conflicting with standard
classes). We currently have the page below with some documentation, but
I have not found much else on the topic:
https://wiki.gentoo.org/wiki/Project:C%2B%2B/Maintaining_ABI

One problem is that depending on the compiler version, the right option
may change (e.g. -std=c++1y vs -std=c++14 and -std=c++1z vs -std=c++17).
This isn't a big problem when using recent compilers, but may be it will
if you want to test some package you develop with an older compiler you
still need to support (out of Gentoo), or if you use ICC, which lags a
bit behind in standards support. For CMake projects, we could set
CMAKE_CXX_STANDARD in cmake-utils.eclass. For other projects we could
use other means. In any case, it might make sense to have global USE
flags like c++11 (already a local USE flag), c++14, etc, along with a
small eclass that C++ projects can inherit to get the right setting
instead of using append-cxxflags with a hard-coded standard version.
Hard-coding the standard flag may create problems because we will have a
mix of the default and the hard-coded ones. The USE flags would also
allow depending on a package with the same standard configuration or
setting the standard globally to something different than the compiler
default (i.e. either stay with C++11 because that's what you need to
work with, or use C++17 since you are on ~arch and your system compiler
supports it, etc).

What are your thoughts on the matter? This has been discussed in the
past¹, but it doesn't seem we have a global solution yet. I think
another discussion happened more recently, but I didn't find the thread.

Cheers,
—Guilherme

1. https://archives.gentoo.org/gentoo-dev/message/eab0dc92cb8adb1457ff368c5a033eaf

[Vadim A. Misbakh-Soloviov]

I'd prefer to wait another replies on the list for the main theme of this e-
mail, but this problem also affects C (so, as **c**flags and C standards), so
solution shoudn't be c++ specific, imho.

[Matt Turner]

I don't understand what a potential solution would be.

The various projects use -std=c++XXX because that's what their code
requires. -std=c++XXX can't generally be changed. If a dependent
project is incompatible that's no different than any other case of
incompatible dependencies in Gentoo.

I think -std=c++XXX discussions before happened because gcc changed
the C++ ABI with -std=c++11. I don't think that's particularly
relevant here, since as far as I know different -std=c++XXX values
don't change the ABI with current gcc.

So I guess my understanding is that there isn't a problem different
than existing incompatible dependencies, but maybe I have
misunderstood you.

[Georg Rudoy]

On 9/17/18 at 5:24 PM user Matt Turner <matt...@gentoo.org> wrote:
> I don't understand what a potential solution would be.
>
> The various projects use -std=c++XXX because that's what their code
> requires. -std=c++XXX can't generally be changed. If a dependent
> project is incompatible that's no different than any other case of
> incompatible dependencies in Gentoo.

It can't generally be downgraded. I'd expect very few post-C++11
packages to actually break when upgrading just the standard.

> I think -std=c++XXX discussions before happened because gcc changed
> the C++ ABI with -std=c++11. I don't think that's particularly
> relevant here, since as far as I know different -std=c++XXX values
> don't change the ABI with current gcc.

noexcept specifier on functions became a part of the function type in
C++17, so it can affect name mangling there.

Given this code:


void no () noexcept (false);
void yes () noexcept (true);

void foo1 (decltype (&no)) {}

void foo2 (decltype (&yes)) {}


the compiler will [1] mangle foo1 and foo2 differently depending on
whether it's built using C++ <= 14 or C++ >= 17.


[1] https://gcc.godbolt.org/z/xmZTBO

--
Georg Rudoy

[Richard Yao]

You would think that, but the C standard version does not effect ABI compatibility. We had a very long discussion about this in OpenZFS because the other platforms were using C99 while we had backported everything to C89 on Linux because of the Linux kernel. No one could find a single example of ABI breakage caused by mixing and matching C89 and C99 (C99 LKM and C89 kernel). After a few years of not a single example being raised, the Linux team lead opted to adopt C99.

Now, there are flags affecting the ABI, but those are separate from the C standard version. As for C++, mixing standard versions does go badly because new language features require ABI changes.
>
>
>

[Guilherme Amadio]

Yes, since mixing standard versions is not so good, and many ebuilds
hard-code it with append-cxxflags, I think it's worth discussing a
better solution that will avoid unnecessary breakage. The big problem
is going from C++14 to C++17 as mentioned before. The 'noexcept' became
part of the mangled name. C++17 also removes features, so there will be
code that will need to be changed to compile as well. If we have a
system-wide setting, we can start warning upstreams about it at least
when things break.

Cheers,
-Guilherme

[Guilherme Amadio]

My concern is with, say, package foo that depends on both bar and baz,
and bar and baz support from C++11 to C++17, but must be compiled with
the same version of the standard so that foo can link against both of
them without having a broken ABI. I think that depending on bar[c++14],
or having a similar mechanism to Python to handle "same version of the
standard" with ${CXXSTD_REQUIRED_USE} or similar in an eclass would be
nice.

Cheers,
-Guilherme

[Dennis Schridde]

Maybe add a CXXABI USE_EXPAND variable and then handle this case similar to
python-single-r1.eclass packages with CXXABI_COMPAT and CXXABI_USEDEP?