Início / unix / Perguntas / 511380
Accepted
daedalus_hamlet
Asked: 2019-04-09 22:48:41 +0800 CST

Por que os sistemas Unix/Linux não percorrem os diretórios até encontrarem a versão necessária de uma biblioteca vinculada?

  • 772

Eu tenho um executável binário chamado "alpha" que requer uma biblioteca vinculada (libz.so.1.2.7) que é colocada em/home/username/myproduct/lib/libz.so.1.2.7

Eu exporto o mesmo para minha instância de terminal antes de gerar meu executável binário executando o seguinte comando.

export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH

Agora, quando eu spawno outro aplicativo "bravo" que requer a mesma biblioteca mas de versão diferente, ou seja (libz.so.1.2.8) que está disponível em /lib/x86_64-linux-gnu/libz.so.1.2.8, o sistema lança o seguinte erro.

version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)

Se eu desabilitar o LD_LIBRARY_PATH, "bravo" inicia bem. Eu entendo que o comportamento acima é porque LD_LIBRARY_PATHtem precedência sobre os caminhos de diretório definidos /etc/ld.so.confao procurar bibliotecas vinculadas e, consequentemente, ocorreu o erro acima. Estou curioso para saber por que os desenvolvedores do UNIX/LINUX não projetaram o sistema operacional para procurar bibliotecas vinculadas em outros diretórios de acordo com a hierarquia se a primeira instância da biblioteca for de versão diferente.

Simplificando, os sistemas UNIX/LINUX percorrem um conjunto de diretórios até encontrar a biblioteca necessária. Mas por que ele não faz o mesmo até encontrar a versão esperada, em vez de aceitar a primeira instância da biblioteca, independentemente de sua versão?

libraries dynamic-linking

1 respostas

  1. Best Answer

    Mas por que ele não faz o mesmo até encontrar a versão esperada, em vez de aceitar a primeira instância da biblioteca, independentemente de sua versão?

    Ele faz, tanto quanto ele está ciente. zlib.so.1.2.7e zlib.so.1.2.8ambos têm um soname de zlib.so.1, então o seu alphae bravoos binários dizem que precisam zlib.so.1. O carregador dinâmico carrega a primeira biblioteca correspondente que encontrar; ele não sabe que a versão 1.2.8 fornece símbolos adicionais bravonecessários. (É por isso que as distribuições se esforçam para especificar informações de dependência adicionais, como zlib1g (>= 1.2.8)para bravo.)

    Você pode pensar que isso deve ser fácil de corrigir, mas não é, principalmente porque binários e bibliotecas listam os símbolos de que precisam separadamente das bibliotecas de que precisam, de modo que o carregador não pode verificar se uma determinada biblioteca fornece todos os símbolos que são necessários a partir dele. Os símbolos podem ser fornecidos de várias maneiras, e a introdução de um link entre os símbolos e as bibliotecas que os fornecem pode quebrar os binários existentes. Há também a diversão adicional da interposição de símbolos para complicar as coisas (e fazer os desenvolvedores sensíveis à segurança arrancarem seus cabelos).

    Algumas bibliotecas fornecem informações de versão que acabam sendo armazenadas em .gnu.version_r, com um link para a biblioteca fornecedora, o que ajudaria aqui, mas libznão é uma delas.

    (Dados os sonames, espero que seu alphabinário funcione bem com zlib.so.1.2.8.)

    • 28

relate perguntas