On 11/30/15 4:52 AM, Michał Górny wrote: > > 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. >
different direction: what about building with rpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/ and then making sure that portage respects that library file during any --depclean or @preserved-rebuild? i'm not sure how we'd inject|||LDFLAGS=-Wl,-rpath=... consistantly and sanely into all c++ builds. this would solve all problems i can see: 1) gcc-config reshuffles /etc/ld.so.conf.d/05gcc-<tuple>.conf but rpath takes presidence, 2) the correct library symbols are guaranteed to be there in both exe and lib. 3) it pro-actively guards against abi mismatches when switching gcc even for other languages like fortran, java, obj-c.| -- 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
