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.
(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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
