Onde o Ubuntu procura bibliotecas compartilhadas?

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

libraries shared-library dynamic-linking

— Dave Lillethun
fonte

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

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:

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.

— Matt H
fonte

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

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.

— Jordan Gee
fonte

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