[Development] Use of std::function in Qt API

Thiago Macieira thiago.macieira at intel.com
Thu Mar 23 20:50:25 CET 2017


On quinta-feira, 23 de março de 2017 12:13:09 PDT Lisandro Damián Nicanor 
Pérez Meyer wrote:
> > The point however is that if libstdc++ does break its ABI, then you'll
> > have
> > to rebuild half the world anyway. The few libraries and applications that
> > did use Qt and were not affected would be the minority. Telling them apart
> > could be a higher cost than just rebuilding -- remember, ALL C++ code
> > links
> > to libstdc++, regardless of whether it was subject to the ABI break or
> > not.
> > 
> > And if libstdc++ changes its soname, then you HAVE to rebuild Qt and
> > everything, anyway.
> 
> Right, but without a proper SONAME change we can not track what needs to get
> rebuilt and what doesn't (because it already was), what can migrate from
> unstable to testing, what binary is compatible with another and so on.

Understood, but that's not Qt's problem. If libc or libstdc++ cause a BC 
break, it's their responsibility to update the SONAME. If they don't, you 
(Debian) get to complain to them.

Either way, the benefit of keeping Qt immune to those breaks is so small to the 
point that it's not worth it.

> > > Oh, and if some non-other Qt api is exposed it should also become part
> > > of
> > > the SONAME.
> > 
> > Again, why? We've exposed C and Xlib API for years and have never had
> > "X11"
> > in the name (or "xcb" now).
> 
> Maybe because they never broke? At least in the time I've been maintaining
> Qt in Debian we have never encountered an issue with this. This is from the
> last Qt 4 releases before Qt5.

Right and that's the entire point: there are some libraries (a whitelist) 
whose types we'll have in our public ABI, so Qt's ABI is then dependent on 
theirs. We'll only add libraries that have a good track record of keeping BC.

So we'll not be having ICU or Boost any time soon in our public ABI. And we 
won't be adding C++1z types or those from TS's or anything std::experimental, 
because as GCC's page makes it very clear: they don't guarantee BC.

> The last time maintainers for other libs had to rename them "by hand" to do
> the proper transition, thus provinding stuff like libfoo5a instead of
> libfoo5. If I remember correctly boost was one of them. Yes, this is
> doable, but means we end up with a different naming scheme than uptream.

Boost is not a BC citizen.

> Now if having distros with different SONAMEs for the same source code is
> acceptable (ie, it doesn't gets coordinated from the Qt project itself) then
> I see no reason to let this happen, after all the C++ ABI doesn't changes
> often.

It's not acceptable. But I don't think it'll come to that.

> > Yet no Linux distribution does that. For 4 years many have provided libc++
> > without opting to this solution. That tells me they are not interested in
> > providing binary compatibility between libstdc++ and other C++ standard
> > library implementations. As a consequence, if they are not, why should we
> > be?
> 
> That's beyond me, as I never digged into it's maintainance.

And that's exactly my point: Linux distributions are not interested.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list