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

[Anthony G. Basile]

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++).

-- 
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