Início / unix / Perguntas / 741134
Accepted
Fred
Asked: 2023-03-28 02:29:51 +0800 CST

Os links simbólicos da biblioteca são usados ​​para carregar bibliotecas?

  • 772

Alguém me disse isso: "Eu sei que os links simbólicos não são usados ​​no Linux ao carregar uma biblioteca".

No entanto, isso não me parece correto. Muitas vezes, tive que consertar links simbólicos quebrados quando estava mexendo no Linux.

Posso encontrar informações sobre links simbólicos, como eles funcionam e como são criados.

Posso encontrar informações sobre bibliotecas compartilhadas e estáticas e como elas funcionam.

Mas não consigo encontrar nenhuma documentação que descreva o processo de carregamento da biblioteca de como os links simbólicos são usados ​​ao carregar bibliotecas. Especialmente quando há várias versões da biblioteca.

Alguém pode me indicar uma documentação que descreva como os links simbólicos são usados ​​para carregar bibliotecas no Linux?

Atualizar

Depois de alguma pesquisa, acredito que a pessoa estava insinuando que os .solinks simbólicos não são usados ​​ao carregar uma biblioteca.

symlink

2 respostas

  1. Best Answer

    É improvável que você encontre qualquer documentação que descreva como as bibliotecas dinâmicas funcionam com links simbólicos porque esses dois conceitos são implementados em diferentes níveis de abstração. Symlinks pertencem a sistemas de arquivos e são transparentes para aplicativos e bibliotecas dinâmicas. Para o programa, um arquivo é apenas um arquivo, seja um arquivo real ou um link simbólico. Todos os trabalhos internos estão ocultos no kernel do sistema operacional.

    • 3

  2. Acontece que não entendi o processo de vinculação às bibliotecas.

    Quando uma biblioteca é vinculada a um programa após sua compilação, ela é vinculada ao soname (que geralmente é o .so.XXarquivo, onde XX é um número de versão) da biblioteca, não à .soversão.

    A execução lddem um aplicativo mostra isso:

    > ldd /opt/GSix/bin/MyApplication 
linux-vdso.so.1 (0x00007ffcefff0000)
/usr/lib64/libsyslognb.so (0x00007fe1eacbc000)
librt.so.1 => /lib64/librt.so.1 (0x00007fe1eaab4000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe1ea897000)
libQt5Widgets.so.5 => /usr/local/Trolltech/Qt-5/lib/libQt5Widgets.so.5 (0x00007fe1e99f5000)
libQt5Gui.so.5 => /usr/local/Trolltech/Qt-5/lib/libQt5Gui.so.5 (0x00007fe1e9143000)
libQt5Core.so.5 => /usr/local/Trolltech/Qt-5/lib/libQt5Core.so.5 (0x00007fe1e894d000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe1e85d2000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe1e82d4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe1e80c2000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe1e7d24000)

    Cada uma dessas bibliotecas tem uma .soversão de link simbólico que aponta para a .so.Xversão principal. Mas lddmostra que o aplicativo não está vinculado à .soversão.

    Isso faz sentido porque permite que várias versões de uma biblioteca sejam instaladas no sistema e cada aplicativo carregará apenas a versão necessária sem entrar em conflito com outras versões.

    Por exemplo, suas bibliotecas de curl podem ter esta aparência:

    16 libcurl.so -> libcurl.so.4
16 libcurl.so.4 -> libcurl.so.4.4.0
387K libcurl.so.4.4.0

16 libcurl.so.3 -> libcurl.so.3.1.0
387K libcurl.so.3.1.0

    Digamos que MyApplication foi vinculado à versão 4 e YourApplication foi vinculado à versão 3.

    Se ambos os aplicativos estivessem procurando por libcurl.so, YourApplication falharia ao carregar porque libcurl.soé um link simbólico para libcurl.so.4.

    É por isso que o aplicativo precisa carregar a .so.Xversão e não a .soversão.

    • 2

relate perguntas