[Development] How to get Qt_5.9.1_PRIVATE_API

Thiago Macieira thiago.macieira at intel.com
Thu Oct 12 17:07:02 CEST 2017


On quinta-feira, 12 de outubro de 2017 00:27:51 PDT Allan Sandfeld Jensen 
wrote:
> On Donnerstag, 12. Oktober 2017 02:47:36 CEST Thiago Macieira wrote:
> > On quarta-feira, 11 de outubro de 2017 13:39:03 PDT Rex Dieter wrote:
> > > The patch's purpose looks appealing, are there "reasons(tm)" it cannot
> > > be
> > > used by default upstream?
> > 
> > Yeah: we don't want to.
> > 
> > It would make the lives of the developers harder: you'd have to recompile
> > everything the moment that the version was bumped and it would make
> > impossible to mix libraries in order to bisect issues.
> 
> Assuming it only applies to private exports, it should only affect libraries
> using private API, 

Which is almost all of them. Remember this applies not just to using privates 
from QtCore, but any privates between any two libraries, such as QtQml and 
QtQuick.

> who should recompile as we do not guarantee ABI for
> those, and in fact have runtime checks in qobject that crashes if the
> private version of a qobjectprivate doesn't match point release of qtbase.

True, but a narrow bisect can find that nothing did change and rebuilding is 
possible. For the example of QtQml and QtQuick, it is possible to rebuild just 
those two and find the problem, without having to rebuild the whole of qtbase, 
qtsvg and qtxmlpatterns, plus whatever else was required to run the test 
itself (suppose it used QtLocation).

> Do you think the Suse patch would also break ABI of applications not using
> private API?

No, it only renames the ELF version we apply to privates. It doesn't change 
which symbols are marked private.

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




More information about the Development mailing list