I think we are mixing two problems that should be handled separately in this
whole thread.
The first one is the question how much of libstdc++ we want to use and expose
in our APIs. The second question is about our BC promise between minor and
patch level releases. Let's keep these two questions separated and don't mix
those in the discussions.
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).
Breaking BC in Qt minor or patch level releases is a totally different
question. So far I have not convincing arguments as to why we would gain a lot
here. We've managed for years to fix our bugs and introduce new features
without breaking BC, I don't see why this should be different now. We will have
a well defined point where we can break BC with Qt 6 and I think it's
beneficial to have these breakages only at well defined points. Let's also not
forget that breaking BC in minor releases would come at a severe cost for the
Linux ecosystem, an ecosystem we want to support as good as we can.
Cheers,
Lars
I think this is something we probably just need to do, as we see more
As we all know there are quite a few things we really would like to use
On 23/11/16 01:05, "Development on behalf of Thiago Macieira"
<development-bounces+lars.knoll=qt...@qt-project.org on behalf of
thiago.macie...@intel.com> wrote:
On quarta-feira, 23 de novembro de 2016 00:07:35 PST Allan Sandfeld Jensen
wrote:
> Can't we statically link to it, so that it doesn't matter which version
the
> application is using?
No, same problem, which is exactly what the Linux distros are doing wrong.
C++ requires certain symbols to be shared and obey ODR: the typeinfo for
the
base types and the virtual tables for some classes (notably,
std::exception).
If we statically link one of the libraries that contains those, then
applications may or may not link to them at runtime. Breaking ODR for those
is
problematic.
The solution is simple: we need to dynamically link to a library that
provides
those and just those. Both libc++ and libstdc++ have such a library:
respectively, libc++abi and libsupc++. Linux distros need to make sure that
only one of those exists and that both libc++ and libstdc++ link to it.
But even if we do that, it doesn't solve the problem of using the std types
in
our ABI, like std::function which we desperately want to use. If our
objective
is to do that, then you can't replace.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
