CODEWITHSUNDEEP
c++qtqt5shared-librariesdynamic-linking
William
William

Reputation: 976

Why program linked against Qt 5.9 cannot run under Qt 5.6?

I have a program built under Qt 5.9 environment. When I copy the program to a server that is installed with Qt 5.6, the program cannot start, with the following error:

./myapp: /usr/lib64/libQt5Core.so.5: version `Qt_5.9' not found (required by ./myapp)

But /usr/lib64/libQt5Core.so.5 does exist, which is a link to libQt5Core.so.5.6.1.

I think the minor version of .so files won't break the compatibility. How does the string `Qt_5.9' enter into myapp and how does it affect the loading of the program?

Upvotes: 0

Views: 591

Answers (2)

Ali Razmkhah
Ali Razmkhah

Reputation: 270

Qt uses a major.minor.patch numbering scheme for Qt releases. For example, Qt 5.0.1 represents the 1st patch release of Qt 5.0. Each release has restrictions on what kind of changes are acceptable, in order to provide a predictable and stable API. This enables users who are only interested in certain types of improvements to be sure that they won't be adversely affected by upgrading to a newer version.

Major releases may break backwards binary and source compatibility, although source compatibility may be maintained.

Minor releases are backwards binary and source compatible.

Patch releases are both backwards and forwards binary and source compatible.

So you cannot run qt 5.9 under qt 5.6!

Upvotes: 1

alexisdm
alexisdm

Reputation: 29886

Minor releases of the Qt libraries only maintain backward binary and source compatibility, meaning that an older executable will work as is with a newer library (see details here).

So if you intend to deploy your program on a server with Qt 5.6, it should be compiled with Qt 5.6 or older, and as long as you don't use features introduced in more recent minor releases, you should be able to recompile with an older release without changing anything.

The version symbol "Qt_5.9" or "Qt_5.6" is stored in both the executable and the library. You can use objdump -p /usr/lib64/libQt5Core.so.5 or objdump -p ./myapp to get either the list of versions with which the library is compatible with (every single minor version is listed), under the section "Version Definitions":

$ objdump -p /usr/lib64/libQt5Core.so.5

/usr/lib64/libQt5Core.so.5:     file format elf64-x86-64

[...]
Version definitions:
1 0x01 0x00028eb5 libQt5Core.so.5
2 0x00 0x0dcbd2c9 Qt_5_PRIVATE_API
3 0x00 0x00058a25 Qt_5
4 0x00 0x058a2810 Qt_5.0
        Qt_5 
5 0x00 0x058a2811 Qt_5.1
        Qt_5.0 
[...]
19 0x00 0x08a28115 Qt_5.15
        Qt_5.14

or the version of the library the executable is compiled for under the section "Version References":

$ objdump -p /bin/qtcreator

/bin/qtcreator:     file format elf64-x86-64

[...]    
Version References:
  required from libQt5Gui.so.5:
    0x00058a25 0x00 12 Qt_5
[...]
  required from libQt5Core.so.5:
    0x08a28115 0x00 06 Qt_5.15
    0x00058a25 0x00 02 Qt_5

Symbols in ELF binaries may be versioned, which means that a version tag might be added to each symbol and the linker may want to import a symbol with a specific version tag. The "Version" sections in the output of objdump seem to come directly from structures inside the binaries (these structures are described here).

For the above example, the qtcreator binary imports symbols from libQt5Core.so.5 with both the Qt_5 and Qt_5.15 version tags, so the binary depends on a library that defines both of those, which should be the case of any library with a version 5.15 and above.

Upvotes: 1

Related Questions