[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.
--
Olivier
More information about the Development
mailing list