Existing .so file cannot be loaded even though it exists, seems to depend on Docker host OS

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](https://github.com/haampie/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. 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? 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. Inspecting the libQt6Core.so itself might give us a clue. It links to a linux-vdso.so.1. According to [this SO question](https://stackoverflow.com/questions/58657036/where-is-linux-vdso-so-1-present-on-the-file-system) , 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 ... ---- 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.