O arquivo .so existente não pode ser carregado mesmo que exista, parece depender do sistema operacional do host do Docker

Eu construí o Qt6 em um contêiner do Docker baseado no Alma8, com o host do Docker sendo o Fedora 35.

Sob algumas circunstâncias (descritas abaixo), todas as bibliotecas Qt não podem carregar arquivos libQt6Core.so[.6[.2.4]]. Mas esse arquivo existe e o diretório correto é pesquisado para esse arquivo. Outras bibliotecas Qt (por exemplo, libQt6Dbus.so) são encontradas e carregadas.

Extensa depuração, reconstrução, pesquisa na web não forneceu nenhuma pista sobre qual é a causa subjacente e como eu poderia corrigi-la.

Localizando o problema

Eu reduzi o problema para o seguinte cenário:

• Criei duas VMs mínimas, uma com centos7 e outra com alma8.
• Instalei o Docker dos repositórios oficiais em ambos.
• Executei a mesma imagem do Docker em ambas as VMs e instalei o mesmo pacote qt6.
• Ele quebra quando o host do Docker é centos7.
• Funciona quando o host do Docker é alma8.

Teoria e pergunta

• O Qt6 foi construído no Alma8 e links para algumas bibliotecas de sistema mais recentes do que o Centos7 fornece, então o Qt6 não pode ser executado no Centos7 (isso é totalmente esperado e correto). Mas deve ser executado em qualquer lugar no contêiner Alma8 Docker.
• As imagens de contêiner devem poder ser executadas em qualquer lugar, mas, neste caso, "algo" do sistema operacional host se infiltra no contêiner e causa o problema - mesmo que ambos os contêineres usem exatamente a mesma imagem!

A questão é: O que é esse "algo" e como/por que ele quebra a compilação?

O que eu tentei

Eu inspecionei libQt6Gui.sopara ver se ele pode ou não carregar libQt6Core.soe inspecionei libQt6Core.sopara ver se algo parece falso usando:

• ldde LD_DEBUG=libs lddque de fato mostrou algumas diferenças (veja abaixo)
• libtree que não mostrou diferenças (mas uma bela árvore :))
• pyldd (de conda-build)
• readelf -d

O que eu também tentei:

• Configuração LD_LIBRARY_PATH(não mudou nada - nenhuma surpresa, pois sei que o caminho correto é sempre pesquisado)
• Construindo o Qt6 em um contêiner alma8 com um host centos7 (falha na compilação com " libQt6Core.so.6: cannot open file", mesmo erro que com a biblioteca construída)
• Construindo o Qt6 em um contêiner centos7 (falha na compilação devido a outros problemas que ainda não consegui corrigir)

Diferenças deldd

Nas capturas de tela abaixo, você vê o Alma8-Docker-Container em um host Centos7 à esquerda e o Alma8-Docker-Container em um host Alma8 à *direita.

As duas primeiras imagens mostram os resultados para ldd /opt/emsconda/lib/libQt6Gui.so. libQt6Corenão pode ser encontrado à esquerda, mas é encontrado à direita.

Esta segunda captura de tela mostra que outras bibliotecas do Qt foram encontradas e carregadas. As bibliotecas ICU também estão faltando à esquerda - talvez elas sejam carregadas apenas quando a libQt6Core também foi carregada?

Esta captura de tela mostra os resultados do LD_DEBUG=libs ldd .... Você pode ver que em ambos os casos, libQt6Coreestá pesquisando no local correto ( /opt/emsconda/lib). Mas só é carregado no recipiente certo. O da esquerda também procura em `/opt/emsconda/lib/./ (haha)) e então caminha silenciosamente para a próxima biblioteca ...

Não consegui encontrar nenhuma mensagem de erro. Este arquivo simplesmente não é aberto/carregado.

Inspecionar o libQt6Core.sopróprio pode nos dar uma pista. Ele liga a um linux-vdso.so.1.

De acordo com esta pergunta SO , esse arquivo é uma biblioteca virtual injetada no espaço do usuário pelo kernel do sistema operacional.

Como os contêineres do Docker não executam seu próprio kernel, suspeito que esse arquivo venha do sistema operacional host. Talvez, libQt6Coredependa de alguma funcionalidade no linux-vdso.so.1que o kernel centos7 não pode fornecer? Eu não faço ideia ...

Como nada que tentei até agora gera uma mensagem de erro, não tenho ideia de qual pode ser o problema real ou como proceder com a depuração. Eu ficaria grato por qualquer tipo de dicas, dicas ou ajuda.