On Sun, 29 Nov 2015 19:56:04 -0800 "Gregory M. Turner" <g...@be-evil.net> 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. Well, it's not that bad actually. After some thinking, I figured out they fixed most 98/11 incompatibilities around gcc 4.8/4.9, and left only a few 'unlikely' to cause issues. However, if one dep switches to C++11, it is quite likely to require C++11 in its revdeps, and that's what happening with libsigc++ and other gtkmm libraries. Plus, there's of course the classical issue of ABI incompatibility between libstdc++ bundled with 4.9 and 5.1, and 5.2... so along with switching g++ version, you soon start to have to rebuild random C++ libraries. And the issue of supporting alternative C++ standard library implementations -- like using libcxx with clang. They are of course incompatible with GNU's ever-changing ABI. > 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. Yes, it is terrible. You end up introducing a lot of USE flags that need to be manually switched along with gcc versions. If we start splitting them between c++98 and c++11, we're quite likely to hit USE flag conflicts between packages/developers which prefer one over another. > 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. Sadly := can't help here since gcc switches occur independently of package installs. And AFAIK revdep-rebuild doesn't help either. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpCK13yp4MMq.pgp
Description: OpenPGP digital signature
