[Development] Tagging private symbols as such
Kevin Kofler
kevin.kofler at chello.at
Wed Dec 7 02:23:15 CET 2016
Thiago Macieira wrote:
> 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.
Yes, but on RPM-based distributions, it would not even install, and the
mismatch would be detected by our automated broken dependency checks. This
is because RPM automatically scans ELF files for dependencies on versioned
symbols and adds a dependency on the "soname(symbol version)" pair. (The
actual symbol names are discarded because there would be just too many to
track. And the version numbers are needed anyway because the symbol can also
change its ABI without changing its name.) That is why OpenSUSE thinks this
is useful, and at least I think it would benefit Fedora too.
> 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 wonder: do we want a different ELF version for the QPA bits, other than
> Qt_5_PRIVATE_API?
IMHO, we want a versioned one, but in both cases. Distinguishing between QPA
and other private bits does not really matter though, if they have the same
(lack of) ABI guarantees.
Kevin Kofler
More information about the Development
mailing list