I feel the same: Let's limit our binary compatibility promise to the part that we can control. That would be Qt itself.
Anyone attempting to build a system with a wider scope of binary compatibility promises needs to also control the shipment of other components, such as libstdc++/libc++, libgcc and others. Simon > On 14 Mar 2017, at 17:20, Thiago Macieira <[email protected]> wrote: > >> On terça-feira, 14 de março de 2017 09:01:25 PDT Ville Voutilainen wrote: >> Ahem, it's not like there weren't qualms about it, but doing it for >> std::string and std::list >> was eventually necessary. The libstdc++ developers (including myself) >> spend fair amounts >> of time and energy trying to avoid abi breakage, including abi >> breakage in downstream libraries. > > I know, and we're grateful for 7 years of no breakage. It was good while it > lasted. > > But then it happened, as we all knew it would. And then it happened again, in > a separate release, instead of everything in one release. > > The cxxabi people also keep a document about a v2 of the ABI itself, so that > will happen some day. > >>> What we have to ask ourselves is whether we want to say that is not our >>> problem. For example, the std::string breakage caused any application or >>> library that used it in its API to need to be recompiled. Besides Qt, >>> there >>> aren't many libraries that avoid it. So if the underlying C++ Standard >>> Library breaks ABI, should we try to work around it? Or should we punt >>> the problem to the user? >> >> I don't know. What do our users want? How big a problem would it be for >> them? > > Right. See also the libc++/libstdc++ mix, which Linux distributions have not, > after years of shipping libc++, done properly. So it seems like mixnig is not > a desired use-case. > > Given that, I'm beginning to think that we should change our policy. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
