1 |
On Sun, 29 Nov 2015 19:56:04 -0800 |
2 |
"Gregory M. Turner" <gmt@×××××××.net> wrote: |
3 |
|
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 |
Well, it's not that bad actually. After some thinking, I figured out |
16 |
they fixed most 98/11 incompatibilities around gcc 4.8/4.9, and left |
17 |
only a few 'unlikely' to cause issues. |
18 |
|
19 |
However, if one dep switches to C++11, it is quite likely to require |
20 |
C++11 in its revdeps, and that's what happening with libsigc++ |
21 |
and other gtkmm libraries. |
22 |
|
23 |
Plus, there's of course the classical issue of ABI incompatibility |
24 |
between libstdc++ bundled with 4.9 and 5.1, and 5.2... so along with |
25 |
switching g++ version, you soon start to have to rebuild random C++ |
26 |
libraries. |
27 |
|
28 |
And the issue of supporting alternative C++ standard library |
29 |
implementations -- like using libcxx with clang. They are of course |
30 |
incompatible with GNU's ever-changing ABI. |
31 |
|
32 |
> I'm not sure we're taking this seriously enough -- sooner or later it |
33 |
> seems destined to become a major clusterfuck if we don't do something |
34 |
> proactive about it now while the drawing-board is relatively |
35 |
> uncluttered. |
36 |
> |
37 |
> The only thing I can think of that has this kind of two-way depgraph |
38 |
> magic property are the major "abi" USE_EXPAND values (multilib-build |
39 |
> and python-r1, in other words). |
40 |
> |
41 |
> But those rely on fancy framework-generated USE-flag deps, which seem |
42 |
> like overkill and likely to incur unjustifiable user-experience-costs. |
43 |
|
44 |
Yes, it is terrible. You end up introducing a lot of USE flags that |
45 |
need to be manually switched along with gcc versions. If we start |
46 |
splitting them between c++98 and c++11, we're quite likely to hit USE |
47 |
flag conflicts between packages/developers which prefer one over |
48 |
another. |
49 |
|
50 |
> Perhaps a solution to this cxx11 clusterfuck can be found that works |
51 |
> more like perl? By that I mean, pick your poison (respectively, your |
52 |
> cxx11 ABI of preference or your major perl version of choice), rely on |
53 |
> inbuilt portage features do the trick most of the time, and, when it |
54 |
> breaks, run "magically-fix-everything.sh," grab a caffeinated beverage |
55 |
> or three and fire up your favorite VOD client while the mess gets |
56 |
> magically cleaned up by robots somehow. |
57 |
|
58 |
Sadly := can't help here since gcc switches occur independently of |
59 |
package installs. And AFAIK revdep-rebuild doesn't help either. |
60 |
-- |
61 |
Best regards, |
62 |
Michał Górny |
63 |
<http://dev.gentoo.org/~mgorny/> |