[Development] Deprecation/removal model going into Qt 6

Olivier Goffart olivier at woboq.com
Wed Jun 5 15:31:25 CEST 2019

On 05.06.19 07:24, Thiago Macieira wrote:
> On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> $ 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.

That's where inline namespaces could help. (You'd change the name of the inline 
namespace as well so you could link to two libraries that use different version 
of Qt, and it would work. (as long as each of these library don't expose Qt in 
their interface))

Having inline namespace could also in theory then allow to link both with Qt5 
and Qt6 in the same process.

But a namespace has the other inconvenient to break every forward declaration.


More information about the Development mailing list