Erro do Linux ao carregar bibliotecas compartilhadas: não é possível abrir o arquivo de object compartilhado: Nenhum arquivo ou diretório

O programa faz parte do conjunto de testes Xenomai, compilado de forma cruzada a partir do Linux PC para o conjunto de ferramentas Linux + Xenomai ARM.

# echo $LD_LIBRARY_PATH /lib # ls /lib ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so ld-linux.so.2 libdl.so.2 libpthread.so.0 libc-2.3.3.so libgcc_s.so libpthread_rt.so libc.so.6 libgcc_s.so.1 libstdc++.so.6 libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9 libcrypt.so.1 libm.so.6 # ./clocktest ./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory 

Edit: OK Eu não notei que o .1 no final fazia parte do nome do arquivo. O que significa isso, afinal?

   

Atualizar
Embora o que eu escrevo abaixo seja verdade como uma resposta geral sobre bibliotecas compartilhadas, acho que a causa mais frequente desses tipos de mensagens é porque você instalou um pacote, mas não instalou a versão “-dev” desse pacote.


Bem, não está mentindo – não há libpthread_rt.so.1 nessa listview. Você provavelmente precisará reconfigurá-lo e reconstruí-lo para que ele dependa da biblioteca que você possui ou instale qualquer coisa que forneça libpthread_rt.so.1 .

Geralmente, os números após o .so são números de versão, e você encontrará frequentemente que eles são links simbólicos uns dos outros, então se você tiver a versão 1.1 do libfoo.so, você terá um arquivo real libfoo.so.1.0, e symlinks foo.so e foo.so.1 apontando para o libfoo.so.1.0. E se você instalar a versão 1.1 sem remover a outra, você terá uma libfoo.so.1.1 e libfoo.so.1 e libfoo.so agora apontarão para a nova, mas qualquer código que exija a versão exata pode use o arquivo libfoo.so.1.0. Código que depende apenas da API da versão 1, mas não se importa se for 1.0 ou 1.1 irá especificar libfoo.so.1. Como mencionado nos comentários, isso é explicado bem em http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .

No seu caso, você pode usar o libpthread_rt.so.1 para libpthread_rt.so . Não há garantias de que ele não vai quebrar seu código e comer seus jantares de TV, no entanto.

Sua biblioteca é uma biblioteca dinâmica. Você precisa informar ao sistema operacional onde ele pode localizá-lo em tempo de execução.

Para fazer isso, precisamos fazer essas etapas fáceis:

(1) Encontre onde a biblioteca é colocada, se você não souber.

 sudo find / -name the_name_of_the_file.so 

(2) Verifique a existência da variável de ambiente do caminho da biblioteca dinâmica ( LD_LIBRARY_PATH )

 $ echo $LD_LIBRARY_PATH 

se não houver nada para ser exibido, adicione um valor de caminho padrão (ou não, se desejar)

 $ LD_LIBRARY_PATH=/usr/local/lib 

(3) Adicionamos o caminho do desejo, exportamos e testamos o aplicativo.

Observe que o caminho deve ser o diretório em que o path.so.something está. Então, se path.so.something estiver em /my_library/path.so.something , deve ser:

 $ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/ $ export LD_LIBRARY_PATH $ ./my_app 

fonte: http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html

Aqui estão algumas soluções que você pode tentar:

ldconfig

Como AbiusX apontou: Se você acabou de instalar a biblioteca, você pode simplesmente precisar executar o ldconfig .

 sudo ldconfig 

O ldconfig cria os links e o cache necessários para as bibliotecas compartilhadas mais recentes encontradas nos diretórios especificados na linha de comando, no arquivo /etc/ld.so.conf e nos diretórios confiáveis ​​(/ lib e / usr / lib).

Normalmente, o seu gerenciador de pacotes cuidará disso quando você instalar uma nova biblioteca, mas nem sempre, e não vai atrapalhar a execução do ldconfig, mesmo que esse não seja o seu problema.

Pacote Dev ou versão errada

Se isso não funcionar, eu também verificaria a sugestão de Paul e procuraria por uma versão “-dev” da biblioteca. Muitas bibliotecas são divididas em pacotes dev e não-dev. Você pode usar este comando para procurá-lo:

 apt-cache search  

Isso também pode ajudar se você simplesmente tiver a versão incorreta da biblioteca instalada. Algumas bibliotecas são publicadas em versões diferentes simultaneamente, por exemplo, Python.

Localização da biblioteca

Se você tem certeza de que o pacote correto está instalado e o ldconfig não o encontrou, ele pode estar em um diretório não padrão. Por padrão, o ldconfig procura em /lib , /usr/lib e diretórios listados em /etc/ld.so.conf e $LD_LIBRARY_PATH . Se sua biblioteca estiver em outro lugar, você pode adicionar o diretório em sua própria linha em /etc/ld.so.conf , append o caminho da biblioteca a $LD_LIBRARY_PATH ou mover a biblioteca para /usr/lib . Em seguida, execute o ldconfig .

Para descobrir onde a biblioteca está, tente isto:

 sudo find / -iname *libraryname*.so* 

(Substitua libraryname pelo nome da sua biblioteca)

Se você usar a rota $LD_LIBRARY_PATH , você vai querer colocar isso no seu arquivo ~/.bashrc para que ele seja executado toda vez que você entrar:

 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library 

Eu tive o erro semelhante, eu poderia resolvê-lo dando,

 sudo ldconfig -v 

Espero que isto ajude.

Você precisa garantir que você especifique o caminho da biblioteca durante a vinculação ao compilar seu arquivo .c:

gcc -I / usr / local / include xxx.c -o xxx -L / usr / local / lib -Wl, -R / usr / local / lib

A parte -Wl, -R informa ao binário resultante para também procurar por biblioteca em / usr / local / lib em tempo de execução antes de tentar usar o arquivo em / usr / lib /

Espero que isso ajude você.

A página de referência do linux.org explica a mecânica, mas não explica a motivação por trás disso 🙁

Para isso, consulte o Sun Linker and Libraries Guide

Além disso, note que o “versioning externo” é largamente obsoleto no Linux, porque o versionamento de símbolos (uma extensão GNU) permite que você tenha múltiplas versões incompatíveis da mesma function para estar presente em uma única biblioteca. Esta extensão permitiu à glibc ter a mesma versão externa: libc.so.6 nos últimos 10 anos.

Tente adicionar LD_LIBRARY_PATH , que indica caminhos de pesquisa, ao seu arquivo ~/.bashrc

 LD_LIBRARY_PATH=path_to_your_library 

Funciona!

 cd /home// sudo vi .bash_profile 

adicione estas linhas no final

 LD_LIBRARY_PATH=/usr/local/lib: export LD_LIBRARY_PATH 

Outra solução possível, dependendo da sua situação.

Se você sabe que libpthread_rt.so.1 é o mesmo que libpthread_rt.so, então você pode criar um symlink por:

 ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1 

Então ls -l /lib deve agora mostrar o link simbólico e para o que ele aponta.

Tudo que eu tive que fazer foi correr:

 sudo apt-get install libfontconfig1 

Eu estava na pasta localizada em /usr/lib/x86_64-linux-gnu e funcionou perfeitamente.

Se você estiver executando seu aplicativo no Microsoft Windows, o caminho para bibliotecas dinâmicas (.dll) precisará ser definido na variável de ambiente PATH.

Se você estiver executando seu aplicativo no UNIX, o caminho para suas bibliotecas dinâmicas (.so) precisará ser definido na variável de ambiente LD_LIBRARY_PATH.

Eu tive um erro semelhante e não foi corrigido com o uso de LD_LIBRARY_PATH em ~ / .bashrc. O que resolveu meu problema é adicionar o arquivo .conf e carregá-lo. Vá para o terminal e esteja no su.

 gedit /etc/ld.so.conf.d/myapp.conf 

Adicione o caminho da biblioteca nesse arquivo e salve (por exemplo: / usr / local / lib). Você deve executar o seguinte comando para ativar o caminho:

 ldconfig 

Verifique seu novo caminho da biblioteca:

 ldconfig -v | less 

Se isso mostra os arquivos da sua biblioteca, então você está pronto para ir.

tente instalar o sudo lib32z1

sudo apt-get instala lib32z1

Eu tive esse erro ao executar meu aplicativo com o Eclipse CDT no Linux x86. Para corrigir isso:

  1. No Eclipse: Executar como> Executar configurações> Ambiente
  2. LD_LIBRARY_PATH = / my_lib_directory_path

O erro ocorre porque o sistema não pode se referir ao arquivo de biblioteca mencionado. Siga os seguintes passos:

  1. Running locate libpthread_rt.so.1 listará o caminho de todos os arquivos com esse nome. Vamos supor que um caminho seja /home/user/loc .
  2. Copie o caminho e execute cd home/USERNAME . Substitua USERNAME pelo nome do usuário ativo atual com o qual você deseja executar o arquivo.
  3. Execute vi .bash_profile e, no final do parâmetro LD_LIBRARY_PATH , um pouco antes . , adicione a linha /lib://home/usr/loc:. . Salve o arquivo.
  4. Feche o terminal e reinicie o aplicativo. Deve correr.

Eu tenho esse erro e acho que é o mesmo motivo de vocês

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

Tente isso. Corrigir permissions em arquivos:

 cd /opt/Popcorn (or wherever it is) chmod -R 555 * (755 if not ok) chown -R root:root * 

“Sudo su” para obter permissions no seu sistema de arquivos.

Eu tenho esse erro e acho que é o mesmo motivo de vocês

Erro ao Carregar Bibliotecas Compartilhadas: libnw.so: não é possível abrir o arquivo de object compartilhado: Nenhum arquivo ou diretório

Tente isso. Corrigir permissions em arquivos:

 cd /opt/Popcorn (or wherever it is) chmod -R 555 * (755 if not ok)