[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