Gentoo Archives: gentoo-dev

From: Mikhail Korolev <stilriv@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] impending c++11 clusterfuck?
Date: Mon, 30 Nov 2015 08:52:28
Message-Id: CAJdFOK1kwMc6CaWaF-Xr0N-61=YJh+17rtZJpRA9p21NLUmgDQ@mail.gmail.com
In Reply to: Re: [gentoo-dev] impending c++11 clusterfuck? by "C Bergström"
1 2015-11-30 7:10 GMT+03:00 C Bergström <cbergstrom@×××××××××.com>:
2 >
3 > On Mon, Nov 30, 2015 at 10:56 AM, Gregory M. Turner <gmt@×××××××.net> wrote:
4 > > I'm quoting myself from bug #566328 here. These were off-the-cuff
5 > > remarks that got away from me and became a call-to-arms...
6 > >
7 > > (In reply to Michał Górny from comment #7)
8 > >> This is never this simple. C++11 can change the ABI. So the point kinda is,
9 > >> we need to ensure that all C++ libraries in a depgraph use the same C++
10 > >> version.
11 > >
12 > > This is pretty awful when you really think about it. I feel like I'm
13 > > watching a train-wreck in super slow motion.
14 > >
15 > > I'm not sure we're taking this seriously enough -- sooner or later it
16 > > seems destined to become a major clusterfuck if we don't do something
17 > > proactive about it now while the drawing-board is relatively
18 > > uncluttered.
19 > >
20 > > The only thing I can think of that has this kind of two-way depgraph
21 > > magic property are the major "abi" USE_EXPAND values (multilib-build
22 > > and python-r1, in other words).
23 > >
24 > > But those rely on fancy framework-generated USE-flag deps, which seem
25 > > like overkill and likely to incur unjustifiable user-experience-costs.
26 > >
27 > > Perhaps a solution to this cxx11 clusterfuck can be found that works
28 > > more like perl? By that I mean, pick your poison (respectively, your
29 > > cxx11 ABI of preference or your major perl version of choice), rely on
30 > > inbuilt portage features do the trick most of the time, and, when it
31 > > breaks, run "magically-fix-everything.sh," grab a caffeinated beverage
32 > > or three and fire up your favorite VOD client while the mess gets
33 > > magically cleaned up by robots somehow.
34 >
35 > I'm not sure I fully understand the problem, but what about
36 > a. Always define the c++11 flag
37 > b. Not support a system with mixed (and incompatible) c++ standards
38 >
39 > I personally don't think it seems reasonable to try to carry both
40 > c++03 and c++11 at the same time. This especially seems like nonsense
41 > to me in the gentoo world. gcc has or will soon switch to c++11 by
42 > default. Packages which can't be built will start having issues
43 > anyway.
44 >
45
46 But there are such packages.
47 ```
48 [ ~ ] # grep "=c++11" /etc/portage/make.conf
49 CXXFLAGS="${CFLAGS} -std=c++11"
50 [ ~ ] # cat /etc/portage/package.env
51 sys-libs/libcxx clang
52 sys-libs/libcxxrt clang
53
54 media-gfx/blender cxxflags_std-gnupp11
55 dev-qt/qtwebkit:4 cxxflags_std-cpp03
56 kde-base/kdelibs:4 cxxflags_std-cpp03
57 media-video/vlc cxxflags_std-gnupp11
58
59 [ ~ ] # ls -d1 /var/db/pkg/*/* | wc -l
60 1294
61 ```