[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

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