Iperf: ldconfig necessário no make install?

Acabei de testar isso no código da ponta do branch master iperf3 no CentOS 6. ldconfig foi invocado para mim como parte de "make install" (parece ser parte do que é feito por libtool --mode = install), e o iperf3 foi capaz de encontrar sua biblioteca compartilhada imediatamente após a instalação, sem necessidade de ldconfig manual. Eu me pergunto se isso é algo específico para uma distribuição Linux?

Outro relato desse problema em outro sistema Ubuntu, os mesmos sintomas. Este sistema era: Ubuntu 12.04.3 LTS (GNU / Linux 3.8.0-31-genérico i686).

Eu me pergunto se ir para um libtool / autoconf / automake mais recente ajudaria neste problema.

OK, eu consegui reproduzir isso em um Ubuntu VM (12.04 LTS, que é claro que eu construí no mesmo dia em que o 14.04 LTS foi lançado). Ainda está se debatendo um pouco no Ubuntu, então ainda não fui tão longe com uma solução.

A execução de ldconfig também foi necessária no Debian Wheezy (7.5) 64 bits. Felicidades,

Atualização: Alguém (esqueci quem era) postou no rastreador de problemas do Google Code que viu esse problema no Ubuntu Trusty (14.04 LTS). Eu também fui capaz de reproduzir isso (de certa forma) no CentOS 6.

O problema parece ser que, depois de instalar as bibliotecas compartilhadas, o goop Makefile gerado automaticamente executa ldconfig -n /usr/local/lib . Isso reconstrói alguns links simbólicos para as bibliotecas recém-instaladas. No entanto, de acordo com ldconfig (8), -n implica -N , o que faz com que o cache da biblioteca compartilhada não seja reconstruído, que é exatamente o problema que estamos vendo. Executar ldconfig sem argumentos reconstrói o cache.

Este parece ser um problema de longa data com alguma combinação de automake e libtool ... muitos detalhes interessantes (embora antigos) aqui:

http://gnu-automake.7480.n7.nabble.com/quot-error-while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file- or-di-td3970.html

Uma sugestão é adicionar algo assim a src/Makefile.am :

install-exec-hook:
        ldconfig

Isso parece ter corrigido o problema ... testado com make install imediatamente seguido pela invocação de iperf3 no CentOS 6 e Ubuntu 12.04 LTS.

Isso causou alguns problemas com as pessoas tentando instalar como um usuário não root (os casos de uso são instalar em uma hierarquia de diretório privado ou construir um RPM como um usuário não root). Basicamente, o ldconfig, conforme invocado, não quer ser executado como não-root porque não teria permissões de arquivo suficientes.

Talvez a invocação do ldconfig deva ser alterada para fazer algo como:

install-exec-hook:
        if [ "x`id -u $USER`" = "x0" ]; then ldconfig; fi

Reabrindo este problema para tentar novamente.

Isso não funciona no MacOS, que não usa ldconfig e, na verdade, causa erros nessa plataforma.

Visando este bug para 3.1. De uma forma ou de outra, precisamos ter algum tipo de resolução para isso, mesmo que seja apenas tendo o item na seção de problemas conhecidos.

Este é realmente um problema genérico de instalação de software. Não vamos resolver isso aqui, devido às dificuldades em fazer isso em várias plataformas. Fechando sem conserto.

Se você quiser manter /usr/local/lib vez de /usr/lib32 na distribuição do Ubuntu, basta executar ldconfig /usr/local/lib (requer root) no final de make install .

Aplique esta solução rápida para permitir que os usuários do Ubuntu instalem o iperf3.

Consulte: http://stackoverflow.com/questions/4743233/is-usr-local-lib-searched-for-shared-libraries

Obrigado executando ldconfig depois que "make install" resolveu o problema para mim.

Executando Debian 7.8 64Bit (wheezy). Tive o problema conforme descrito no título, executei 'sudo ldconfig' pós make install, funcionando bem agora. Obrigado pela ajuda neste tópico.

Tive que usar isso na versão mais recente (3.1.3) com o Ubuntu. Se este for um requisito necessário para todas as versões do ubuntu, sugiro que vale a pena torná-lo um pouco mais óbvio para que o usuário não precise pesquisar no google / github para começar

O mesmo aqui com Ubuntu 16.04 (Xenial Xerus).
ubuntu é melhor fazer sinais de alerta sobre isso, a menos que alguém como eu se perca novamente ....

Alguém tem uma correção para o erro iperf3 no Mac OSX? Com iperf3 3.2, usando o wrapper Python, estou vendo que libiperf.so.0 não foi encontrado.

@ jmack51 : No mac OS, não haverá uma biblioteca compartilhada *.so.0 ... o mac OS usa uma extensão *.dynlib para suas bibliotecas compartilhadas. Se "o invólucro Python" se refere a iperf3-python, esse é um projeto separado e você provavelmente deve levar isso em consideração (não tenho certeza se há um bug aqui ou não).

@ jmack51 : Ah, desconsidere, vejo onde você já abriu um problema com thiezn / iperf3-python.

Obrigado Bruce, desculpe pelo spam, para o registro que acabou em https://github.com/thiezn/iperf3-python/issues/23

Vou reabrir este problema, embora não tenha uma boa ideia sobre como corrigi-lo. Existem vários casos de uso:

• Sistemas que precisam do ldconfig para serem executados.
• Sistemas que não precisam de ldconfig.,
• Sistemas que precisam de ldconfig com alguns parâmetros (por exemplo, um nome de caminho).
• Sistemas sem ldconfig (por exemplo, macOS).
• Compilação cruzada.

Estou pensando em algo como o que propus em 10 de junho de 2014, mas ignorando as condições de erro. Seria ótimo se alguém pudesse comentar sobre o caso de compilação cruzada ... se você está compilando para alguma outra plataforma, faça o make install completo para armazenar os arquivos em algum lugar ou apenas make compile ?

Encontrei esse problema e espero que você possa me ajudar a encontrar uma solução.

Estou tentando executar iperf3 em meu armv5 QNAP NAS.

Consegui instalar. Mas, ao executá-lo, recebo este problema: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (sem ou sem sudo) não corrigiu isso infelizmente.

[/] # find . -name libiperf.so.*
./mnt/ext/usr/local/lib/libiperf.so.0
./mnt/ext/usr/local/lib/libiperf.so.0.0.0
./share/HDA_DATA/homes/admin/downloads/iperf-3.5/src/.libs/libiperf.so.0.0.0
./share/HDA_DATA/homes/admin/downloads/iperf-3.5/src/.libs/libiperf.so.0

ls -la de / dá
lrwxrwxrwx 1 admin administ 12 Mar 30 10:18 usr -> /mnt/ext/usr/

[/usr/local/lib] # ls -la libiperf.s*
lrwxrwxrwx    1 admin    administ        17 Mar 30 21:32 libiperf.so -> libiperf.so.0.0.0*
lrwxrwxrwx    1 admin    administ        17 Mar 30 21:32 libiperf.so.0 -> libiperf.so.0.0.0*
-rwxr-xr-x    1 admin    administ    380032 Mar 30 21:32 libiperf.so.0.0.0*

Tentei adicionar /mnt/ext/usr/local/lib a /etc/ld.so.conf e _então_ correndo ldconfig sem sorte.

Era assim que parecia antes (e desde então removi novamente):

[/mnt/ext/usr/local/lib] # cat /etc/ld.so.conf 
/lib
/usr/lib
/usr/local/lib

O que posso fazer / tentar?

@BeyondEvil você tentou usar a variável de ambiente LD_LIBRARY_PATH?

@ralcini Não, não tenho, (eu acho). Vou dar uma chance. 👍

Para a consulta de compilação cruzada em https://github.com/esnet/iperf/issues/153#issuecomment -365012358, usei make install extensivamente. Eu acho que a maioria dos sistemas de construção também faz isso - principalmente se um projeto for autotoolizado.

Eu sugeriria, como primeira tentativa, o processo de construção do iperf poderia colocar mensagens no console sugerindo o comando que deveria ser executado. Assim que tivermos isso, passe para realmente fazer.

Existe uma lista de quais sistemas (* nix) precisam do ldconfig para ser executado e quais não? O macOS e o Windows entram na lista de não exigir que o ldconfig seja executado após o make install.

À parte, estou curioso para saber quais sistemas não precisam do ldconfig para rodar e como isso é gerenciado.

Fechando. Este não é apenas um problema iperf3, e parece que ninguém mais tem uma boa solução para ele. (Eu diria que alguma combinação de automake e libtool deve lidar com esse problema.)

Sim, parece um problema da libtool. A última vez que fui atrás disso, encontrei o seguinte no rastreador de bugs GNU:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30402

Em 1997, comprometa 7f9b4e50 para libtool versão 0.6b, a forma de execução
ldconfig foi alterado de execução sem "-n" para execução com "-n".

Com base na discussão ali, parece improvável que isso seja revertido, uma vez que muito tempo se passou e a justificativa para a mudança e o potencial de risco de revertê-la parecem ser mal compreendidos. Se alguém se deparar com esse problema no futuro e quiser tentar consertá-lo de qualquer maneira, provavelmente será o mais próximo que você conseguirá de fazer isso corretamente.