[Development] Tagging private symbols as such

[Thiago Macieira]

Em quarta-feira, 7 de dezembro de 2016, às 02:23:15 PST, Kevin Kofler escreveu:
> > I think I had thought of that when I originally came up with the idea, but
> > discarded it. I know I don't want it in developer builds for the same
> > reason that QObjectPrivate's constructor does not complain about mixing Qt
> > versions in developer builds (see 5bf67f5f41ab110eb41ab74f2a87e649735af435
> > for the rationale). But unlike the QObjectPrivate check, changing the ELF
> > version according to Qt version would render a -developer-build library
> > binary- incompatible with a non-developer-build user.
> > 
> > I may have had other reasons, but I don't remember them now.
> > 
> > So I think it's not a good idea to apply the SUSE patch as-is.
> 
> But applying it downstream in distribution packages should be OK in any
> case, shouldn't it? I don't think binary compatibility with upstream makes
> sense for private symbols which are not even guaranteed to be compatible
> between two upstream version.

I would rather distros not produce binary-incompatible patches to upstream Qt. 
This is such a patch.

And I was actually affected by it: I wanted to backport an XRandR bugfix to 
libQt5XcbQpa, so I just built my own check out of qtbase on the tag + cherry-
pick. But the lib wouldn't load because the ELF versions were different. I had 
to install qmake & qtbase development files from the distro so it would build 
and load.

I'd like to come to an agreement.

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