Re: [gentoo-dev] impending c++11 clusterfuck?

[Anthony G. Basile]

On 11/30/15 4:52 AM, Michał Górny wrote:
>
> Dnia 30 listopada 2015 09:07:30 CET, "Anthony G. Basile" <blueness@g.o> 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" <gmt@×××××××.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    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA