From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EAB31138334 for ; Tue, 18 Sep 2018 14:26:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 960D1E0D74; Tue, 18 Sep 2018 14:26:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 45268E0900 for ; Tue, 18 Sep 2018 14:26:17 +0000 (UTC) Received: from gentoo.org (unknown [IPv6:2001:1458:202:96::101:7295]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: amadio) by smtp.gentoo.org (Postfix) with ESMTPSA id 6533F335CE7 for ; Tue, 18 Sep 2018 14:26:13 +0000 (UTC) Date: Tue, 18 Sep 2018 16:26:08 +0200 From: Guilherme Amadio To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] C++ standard in ebuilds Message-ID: <20180918142607.GA25320@gentoo.org> References: <20180917153738.GA5402@gentoo.org> <3229421.CvTK6SVxHl@tp> <812A3F5E-AA6A-4FFA-BF70-EE8B6565A6DF@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <812A3F5E-AA6A-4FFA-BF70-EE8B6565A6DF@gentoo.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: e1f239ff-286b-42c7-84af-e4ffce4220da X-Archives-Hash: 7f164ff4929d6bc43975e02957ef5f8d On Tue, Sep 18, 2018 at 08:46:46AM -0400, Richard Yao wrote: > > > On Sep 17, 2018, at 12:40 PM, Vadim A. Misbakh-Soloviov wrote: > > > > 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. > 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. > > 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