[Development] Tagging private symbols as such

Thiago Macieira thiago.macieira at intel.com
Wed Dec 7 01:26:41 CET 2016


Em terça-feira, 6 de dezembro de 2016, às 20:44:06 PST, Lisandro Damián 
Nicanor Pérez Meyer escreveu:
> If I understand the patch correctly that would effectively change the symbol
> version on each new patch release. That's something at least us in Debian
> would like to avoid, but again, if it's useful for someone else, we can
> always patch it out.

It would change the ELF version for private symbols. The idea, I guess, is 
that if you forgot to rebuild, then the old .so fails to load. With the same 
ELF version, it would load and may do bad things.

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. The QPA part 
makes sense, though.

I wonder: do we want a different ELF version for the QPA bits, other than 
Qt_5_PRIVATE_API?

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




More information about the Development mailing list