On 11/30/15 1:42 AM, Michał Górny wrote: > 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. When building a package, you can't just switch between -std=gnu++98 or c++99 or gnu++11 or c++11 since there are syntactic difference. > > 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.
This would be a nightmare. > >> 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. You can run `revdep-rebuild -L 'libstdc\+\+\.so\.6'` to rebuild everything that links against libstdc++.so.6. This will rebuild a lot of packages but will fix everything. If we record enough information at build time (eg. gcc version or libcxx/clang) then we can build tools that intelligently predict if there's an abi incompatibility. Unfortunately gcc doesn't bump soname and/or version-info when it changes c++11 abi. (since c++11 is experimental and c++03/98 have stable abi, they don't want to force rebuilds). So we have to record the equivalent of an soname. If we put that information in a file like NEEDED.ELF.2 in vdb, it could be read by utilities like magically-fix-everything.sh (a revddep-rebuild.sh for libstdc++). -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
