[Development] Summary ABI compabilty

[Lars Knoll]

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.io at qt-project.org on behalf of thiago.macieira at 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 at qt-project.org
    http://lists.qt-project.org/mailman/listinfo/development