[Development] Deprecation/removal model going into Qt 6

Thiago Macieira thiago.macieira at intel.com
Wed Jun 5 07:24:40 CEST 2019

On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer 
> $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME
>  SONAME               libQt5Core.so.5

Note the two numbers in the SONAME. They mean two different thing. Right now, 
they are equal but they don't have to be.

The first one, the one that is part of the library name itself, as found in 
the -l switch to the compiler, is the *source* version. Newer releases of a 
library that keeps the same source version indicate that they retained source 
compatibility with older versions of that library.

The second one, the one that only appears after you link, is the binary 
version. Whenever we break source compatibility, that number changes.

So we could have libQt6Core.so.0 released in Qt 6.0, then ibQt6Core.so.1 in Qt 
6.3. This would allow both libraries to be co-installable, so applications and 
libraries that haven't been recompiled can still run, without getting broken.

However, the two libraries are not loadable at the same time into memory. And 
there's also no mechanism that would prevent that from happening. So it's 
entirely up to the distributor or integrator to make sure that is properly 
done, including by way of a plugin load. If two binary incompatible versions 
of the same library get accidentally loaded into memory, very weird things 
will happen, with really hard to debug issues.

So, no, I do not recommend doing this.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

More information about the Development mailing list