Onde o Ubuntu procura bibliotecas compartilhadas?


24

Quando executo um processo vinculado a uma biblioteca compartilhada em tempo de execução (vinculado quando o processo é iniciado, não vinculado posteriormente dlload()), onde ele procura esse .soarquivo de biblioteca compartilhada ( ) diferente de LD_LIBRARY_PATH?

Fundo:

Eu tenho algum código C ++ que escrevi que usa uma biblioteca de terceiros específica. Instalei a biblioteca e compilei meu código em duas plataformas diferentes, Ubuntu, mas versões diferentes e versões diferentes do gcc. A biblioteca foi compilada e instalada a partir da fonte e está localizada em /usr/local/libambas as plataformas. Ao compilar meu código, vinculo-me aos pkg-config --libsparâmetros da biblioteca de terceiros e verifiquei que pkg-config --libsretorna exatamente a mesma coisa nas duas plataformas.

Meu código é compilado com êxito nas duas plataformas e LD_LIBRARY_PATHnão está definido (ou definido como vazio :) ""nas duas plataformas. No entanto, quando eu o executo em um platoform, ele funciona bem e, por outro, recebo este erro:

error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory

Curiosamente, o que não funciona é a versão mais recente do Ubuntu e gcc. : /

Então, eu estou tentando descobrir como o que está trabalhando é capaz de localizar a biblioteca, para que eu possa fazer com que o quebrado localize a biblioteca da mesma maneira. (ou seja, sem configuração LD_LIBRARY_PATH)

Atualizar:

Aqui está a minha saída de cat /etc/ld.so.conf.d/*

... no sistema de trabalho (mais antigo):

/usr/lib/mesa
/usr/lib32/mesa
/usr/lib/alsa-lib
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

... no sistema quebrado (mais recente):

# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa

1
Acho que esses lugares estão definidos /etc/ld.so.conf.d/*.conf, mas não tenho certeza disso.
Salem

Parece, mas veja a minha atualização para o OQ para o conteúdo desses arquivos ... Parece que ele deve encontrar, /usr/local/lib/libthrift-0.9.0.somas ainda dá o erro error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory... Existe algum motivo para não escolher um diretório /etc/ld.so.conf.d/*.conf?
Dave Lillethun 25/09

3
Tente executar sudo ldconfig -vcomo sugerido abaixo. Se ainda assim não funcionar, atualize sua pergunta com a saída de ldd /path/to/your/application.
Salem

Respostas:


29

Todo esse negócio de caminho está relacionado a algo chamado multi-arco. Basicamente, é para permitir que você tenha bibliotecas de 32 bits e 64 bits no mesmo sistema.

Depois de copiar o arquivo, você executou o ldconfig?

ldconfig  creates,  updates,  and removes the necessary links and cache
       (for use by the run-time linker,  ld.so)  to  the  most  recent  shared
       libraries  found  in  the directories specified on the command line, in
       the file /etc/ld.so.conf, and in the trusted directories (/usr/lib  and
       /lib).   ldconfig  checks the header and file names of the libraries it
       encounters when determining which  versions  should  have  their  links
       updated.  ldconfig ignores symbolic links when scanning for libraries.

Eu corri sudo ldconfige isso resolveu o problema! (Não precisava recompilar meu código ou algo assim ...) Eu só quero entender ... Você disse "Depois de copiar o arquivo", mas eu não copiei um arquivo. Você quer dizer depois que eu construí e instalei a biblioteca ou depois que compilei meu programa?
Dave Lillethun

Depois que você o colocou onde você o colocou. Basicamente, um cache de biblioteca é construído. Eu acho que a reinicialização também pode reconstruir o cache.
Matt H

Posso estar enganado, mas acredito que reiniciei desde a instalação da biblioteca ... No entanto, sudo ldconfigfiz o truque. Isso é algo que as bibliotecas costumam executar automaticamente para você como parte da instalação delas, e essa, por algum motivo, não? Basta saber por que eu não "normalmente" ter que fazer isso, mas não só neste caso ...
Dave Lillethun

Normalmente, a instalação do pacote executará o ldconfig durante o processo de instalação, eu acho. Talvez a versão da sua distribuição mais recente não esteja funcionando por algum motivo.
Matt H

1

As informações contidas na pergunta acima E a primeira (e única ATT) resposta me ajudaram a resolver * um problema semelhante * meu no WSL Ubuntu (no Win10 64)!

No meu caso, o executável não conseguiu encontrar uma biblioteca. I última análise, percebeu que a biblioteca recém-made foi posicionado no /usr/lib64, mas as linhas de multi-arco de /etc/ld.so.conf.d/x86_64-linux-gnu.conf que não incluem o diretório.

Então eu corri

sudo ldconfig /usr/lib64

e isso finalmente consertou. (executá-lo sozinho, sem o parâmetro de diretório não fazê-lo 'magicamente' encontrar as bibliotecas BTW.) Não está claro se 'reiniciar' o meu WSL festa ajudou ... Eu acho que não foi sequer necessário.


O mesmo aconteceu comigo com / usr / local / lib /. Criei um arquivo /etc/ld.so.conf.d/usr-local.confe, em seguida, executei sudo ldconfigsem efeito - as bibliotecas nesse diretório não foram encontradas pelo carregador. Depois de executar sudo ldconfig /usr/local/libtudo funcionou bem.
Josh Milthorpe
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.