I'm quoting myself from bug #566328 here. These were off-the-cuff remarks that got away from me and became a call-to-arms...
(In reply to Michał Górny from comment #7) > This is never this simple. C++11 can change the ABI. So the point kinda is, > we need to ensure that all C++ libraries in a depgraph use the same C++ > version. This is pretty awful when you really think about it. I feel like I'm watching a train-wreck in super slow motion. I'm not sure we're taking this seriously enough -- sooner or later it seems destined to become a major clusterfuck if we don't do something proactive about it now while the drawing-board is relatively uncluttered. The only thing I can think of that has this kind of two-way depgraph magic property are the major "abi" USE_EXPAND values (multilib-build and python-r1, in other words). But those rely on fancy framework-generated USE-flag deps, which seem like overkill and likely to incur unjustifiable user-experience-costs. Perhaps a solution to this cxx11 clusterfuck can be found that works more like perl? By that I mean, pick your poison (respectively, your cxx11 ABI of preference or your major perl version of choice), rely on inbuilt portage features do the trick most of the time, and, when it breaks, run "magically-fix-everything.sh," grab a caffeinated beverage or three and fire up your favorite VOD client while the mess gets magically cleaned up by robots somehow. -gmt Greg Turner g...@be-evil.net
