Dnia 30 listopada 2015 12:17:32 CET, "Anthony G. Basile" <bluen...@gentoo.org> napisał(a): >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.|
I'm afraid any of those problems are really affecting us here. GCC maintains backwards ABI compatibility in the library, so applications will continue to work as long as runtime libstdc++ isn't older than build time. Currently, we always force newest installed libstdc++ at runtime, and use the version matching GCC version at build time, so that works. So the best thing your solution could give us is loading the wrong version of libstdc++ when you link to a library built against older one. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
