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

[Michał Górny]

Dnia 30 listopada 2015 12:17:32 CET, "Anthony G. Basile" <blueness@g.o> napisał(a):
>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.|

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.