[Development] Summary ABI compabilty

[Konstantin Tokarev]

25.11.2016, 03:38, "Kevin Kofler" <kevin.kofler at chello.at>:
> Lars Knoll wrote:
>>  There are a lot of good arguments towards using the STL and libstdc++
>>  more, as it will allow us to interoperate better with the C++ standard,
>>  and provides a couple of things that we really want to use. So I can see
>>  many good arguments towards going down that route. Doing so will bind the
>>  compiled Qt binary to a certain version of that library (ie, it will
>>  require a recompile of Qt to switch from libc++ to libstdc++). To a large
>>  extent that is no different than the situation we're facing with e.g.
>>  different VC++ runtimes. It also doesn't create impossible challenges for
>>  the Linux packagers/distributors (or at least the challenges won't be
>>  caused by us). So I'm positive towards using more of the standard
>>  functionality and APIs (and also exposing them in our APIs).
>
> libstdc++ now has a sub-ABI-version that was already bumped recently for
> better C++11 compliance. It can be bumped again, without even changing the
> soname, and all libraries using the std:: types in their APIs will have a
> broken ABI.
>
> That would leave us distributors only with very unpleasant solutions:
> (a) rebuild everything using Qt in reverse dependency order, which has to be
>     computed first. Alphabetic order, as normally used by the Fedora mass
>     rebuild scripts, will almost certainly not work, due to symbol lookup
>     failures.

Gentoo provides revdep-rebuild for ages. Looks like you guys are stuck with crappy tooling.

> (b) pin libstc++ to an old version forever.
> (c) patch libstdc++ to stick to the old ABI forever.
> (d) tweak the build flags of Qt, everything using Qt, all C++ libraries it
>     uses, everything using those libraries, etc., propagating back and
>     forth, to stick to the old ABI forever. That is likely all or almost all
>     C++ stuff in the distribution. So (d) is probably just a very
>     complicated way to implement (c).
> (e) hack things up so that Qt uses the old ABI types for its own APIs
>     (forever), but the new ABI types for libraries it uses that have already
>     been rebuilt. That requires patching Qt with libstdc++-specific hacks
>     and maintaining those patches forever.
>
> Neither of those is really acceptable.
>
>         Kevin Kofler
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin