I have built Qt6 in an Alma8 based Docker container, with the Docker host being Fedora 35.

Under some circumstances (described below), all Qt libs cannot load libQt6Core.so[.6[.2.4]]. But that file exists and the correct directory is searched for that file. Other Qt libs (e.g., libQt6Dbus.so) are found and loaded.

Extensive debugging, re-building, seaching-the-web did not yield any clues what the underlying cause is and how I could fix it.

Locating the problem

I have narrowed down the problem to the following scenario:

  • I created two minimal VMs, one with centos7 and one with alma8.
  • I installed Docker from the official repos into both of them.
  • I ran the same Docker image in both VMs and installed the same qt6 package.
  • It breaks when the Docker host is centos7.
  • It works when the Docker host is alma8.

Theory and Question

  • Qt6 was built on Alma8 and links to some system libraries newer than what Centos7 provides, so Qt6 cannot run unter Centos7 (this is totally expected and okay). But it should run anywhere in the Alma8 Docker container.
  • Container images should be able to run anywhere, but in this case "something" from the host OS sneaks into the container and causes the Issue – even though both containers use the exact same image!

The question is: What is this "something" and how/why does it break the build?

What I tried

I inspected libQt6Gui.so to see whether or not it can load libQt6Core.so and I inspected libQt6Core.so to see if something looks bogus using:

  • ldd and LD_DEBUG=libs ldd which indeed showed some differences (see below)
  • libtree which showed no differences (but a nice tree :))
  • pyldd (from conda-build)
  • readelf -d

What I also tried:

  • Setting LD_LIBRARY_PATH (did not change anything – no surprise since I know that the correct path is always searched)
  • Building Qt6 in an alma8 container with a centos7 host (build failed with "libQt6Core.so.6: cannot open file", same error as with the built lib)
  • Building Qt6 in a centos7 container (build failed due to other problems I could not yet fix)

Differences from ldd

In the screenshots below, you see a the Alma8-Docker-Container on a Centos7 host on the left and the Alma8-Docker-Container on an Alma8 host on the *right.

The first two images show the results for ldd /opt/emsconda/lib/libQt6Gui.so. libQt6Core can not be found on the left but is found on the right.

enter image description here

This second screenshot shows that other Qt libs are found and loaded. The ICU libs are also missing on the left - maybe they are only loaded when libQt6Core was also loaded?

enter image description here

This screenshot shows the results of LD_DEBUG=libs ldd .... You can see that in both cases, libQt6Core is search in the correct location (/opt/emsconda/lib). But it is only loaded in the right container. The left one additionally looks in `/opt/emsconda/lib/./ (haha)) and then silently walks on to the next lib ...

I could not find any error messages. This file is just not opened/loaded.

enter image description here

Inspecting the libQt6Core.so itself might give us a clue. It links to a linux-vdso.so.1.

According to this SO question, that file is a virtual lib injected into the userspace by the OS kernel.

Since Docker containers do not run their own kernel, I suspect that that file comes from the host OS. Maybe, libQt6Core relies on some functionality in the linux-vdso.so.1 that the centos7 kernel cannot provide? I have no idea ... enter image description here

Since nothing I tried so far yields an error message, I have no clue what the acutal problem might be or how to proceeded with debugging. I'd be greatful for any kind of hints, tips or help.

  • I get the same error when I pip install pyside6 (libQt6Core.so.6: cannot open shared object file: No such file or directory). So I’m relatively certain that it is not the way I compiled qt6 that causes the issue. Commented Apr 25, 2022 at 11:55

1 Answer 1


The question got answer in the Qt forums.


  • The .so contains an ABI tag that denotes the minimum kernel version required. You can see this via objdump -s -j .note.ABI-tag libQt6Core.so.6.2.4. The result is in the last three blocks (0x03 0x11 0x00 -> 3.17.0 in my case).
  • This information is placed there on purpose since QT uses a few system calls that are only available with newer kernels.
  • Glibc reads this information when it loads a shared object and compares it to the current kernel's version. If it doesn't match, the file is not loaded.
  • Since Docker has no own kernel, the Docker host’s kernel version is used for that comparison. So even if the Docker image is Alma8, the kernel is still the old v3.10.0 from the Centos7 host in my case.
  • You can use strip --remove-section=.note.ABI-tag libQt6Core.so.6.2.4. Qt seems to have fallback code, so nothing breaks.

Source: https://github.com/Microsoft/WSL/issues/3023

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .