From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 302F11384B4 for ; Mon, 30 Nov 2015 11:17:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12CDA21C07F; Mon, 30 Nov 2015 11:17:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0593E21C071 for ; Mon, 30 Nov 2015 11:17:37 +0000 (UTC) Received: from greysprite.dite (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 1D66F33D3D0 for ; Mon, 30 Nov 2015 11:17:35 +0000 (UTC) Subject: Re: [gentoo-dev] impending c++11 clusterfuck? To: gentoo-dev@lists.gentoo.org References: <4065232.vgWU8t9PnH@moneypit> <20151130074235.5a0fec7b.mgorny@gentoo.org> <565C03C2.6020209@gentoo.org> <9B7A7F91-7510-4144-8745-AC9AB264C817@gentoo.org> From: "Anthony G. Basile" X-Enigmail-Draft-Status: N1110 Message-ID: <565C304C.8060202@gentoo.org> Date: Mon, 30 Nov 2015 06:17:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <9B7A7F91-7510-4144-8745-AC9AB264C817@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 00708b39-86a5-4b12-924e-1813b6f36a22 X-Archives-Hash: 321bd9ca8abe0a0e50d82003b1a1dca1 On 11/30/15 4:52 AM, Micha=C5=82 G=C3=B3rny wrote: > > Dnia 30 listopada 2015 09:07:30 CET, "Anthony G. Basile" napisa=C5=82(a): >> On 11/30/15 1:42 AM, Micha=C5=82 G=C3=B3rny wrote: >>> On Sun, 29 Nov 2015 19:56:04 -0800 >>> "Gregory M. Turner" 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=C5=82 G=C3=B3rny 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. =20 >>>> 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=3Dgnu++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 :=3D 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++ librarie= s) 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=3D/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=3D-Wl,-rpath=3D... 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-.conf but rpath takes presidence, 2) the correct library symbols are guaranteed to be there in both exe and lib.=20 3) it pro-actively guards against abi mismatches when switching gcc even for other languages like fortran, java, obj-c.| --=20 Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA