Dnia 30 listopada 2015 09:07:30 CET, "Anthony G. Basile" <bluen...@gentoo.org> napisał(a): >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++).
In my case, checking CXX + library symbols (to distinguish C++ libraries) works. But most of the people believe setting CXX to a static version is a bad idea, and it's better to use implicit magic of gcc-config. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
