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

[Michał Górny]

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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.