On Mon, Nov 30, 2015 at 10:56 AM, Gregory M. Turner <[email protected]> wrote: > 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.
I'm not sure I fully understand the problem, but what about a. Always define the c++11 flag b. Not support a system with mixed (and incompatible) c++ standards I personally don't think it seems reasonable to try to carry both c++03 and c++11 at the same time. This especially seems like nonsense to me in the gentoo world. gcc has or will soon switch to c++11 by default. Packages which can't be built will start having issues anyway.
