Iperf: ldconfig nécessaire dans make install?

Je viens de tester cela sur le code de la pointe de la branche master iperf3 sur CentOS 6. ldconfig a été invoqué pour moi dans le cadre de "make install" (cela semble faire partie de ce qui est fait par libtool --mode = install), et l'iperf3 a pu trouver sa bibliothèque partagée immédiatement après l'installation, aucun ldconfig manuel n'est nécessaire. Je me demande si c'est quelque chose de spécifique à une distribution Linux?

Un autre rapport de ce problème sur un autre système Ubuntu, mêmes symptômes. Ce système était: Ubuntu 12.04.3 LTS (GNU / Linux 3.8.0-31-generic i686).

Je me demande si aller à un nouveau libtool / autoconf / automake aiderait ce problème?

OK, j'ai pu reproduire cela sur une VM Ubuntu (12.04 LTS, que j'ai bien sûr construite le jour même de la sortie de 14.04 LTS). Encore un peu agité sur Ubuntu, donc je n'ai pas encore vraiment avancé avec une solution.

L'exécution de ldconfig était également nécessaire sur Debian Wheezy (7.5) 64 bits. À votre santé,

Mise à jour: Quelqu'un (j'oublie de qui il s'agissait) a signalé au suivi des problèmes de Google Code qu'il avait vu ce problème sur Ubuntu Trusty (14.04 LTS). J'ai également pu reproduire ceci (après une certaine façon) sur CentOS 6.

Le problème semble être qu'après l'installation des bibliothèques partagées, le goop Makefile généré automatiquement exécute ldconfig -n /usr/local/lib . Cela reconstruit certains liens symboliques pour les bibliothèques nouvellement installées. Cependant, selon ldconfig (8), -n implique -N , ce qui empêche la reconstruction du cache de la bibliothèque partagée, ce qui est exactement le problème que nous voyons. Lancer ldconfig sans argument reconstruit le cache.

Cela semble être un problème de longue date avec une combinaison d'automake et de libtool ... beaucoup de détails intéressants (même si anciens) ici:

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

Une suggestion est d'ajouter quelque chose comme ceci à src/Makefile.am :

install-exec-hook:
        ldconfig

Cela semble avoir résolu le problème ... testé avec make install immédiatement suivi de l'invocation iperf3 sur CentOS 6 et Ubuntu 12.04 LTS.

Cela a causé quelques problèmes avec les personnes essayant d'installer en tant qu'utilisateur non root (les cas d'utilisation sont l'installation dans une hiérarchie de répertoires privés ou la construction d'un RPM en tant qu'utilisateur non root). Fondamentalement, ldconfig tel qu'il est appelé ne veut pas être exécuté en tant que non-root car il manquerait d'autorisations de fichier suffisantes.

Peut-être que l'invocation de ldconfig devrait être modifiée pour faire quelque chose comme:

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

Rouvrir ce numéro pour réessayer.

Cela ne fonctionne pas sur MacOS, qui n'utilise pas ldconfig, et provoque en fait des erreurs sur cette plate-forme.

Cibler ce bogue pour la version 3.1. D'une manière ou d'une autre, nous devons avoir une sorte de résolution pour cela, même s'il s'agit simplement d'avoir l'élément dans la section des problèmes connus.

C'est vraiment un problème d'installation de logiciel générique. Nous n'allons pas le résoudre ici, étant donné les difficultés à le faire sur plusieurs plates-formes. Fermeture sans solution.

Si vous voulez vous en tenir à /usr/local/lib au lieu de /usr/lib32 sur la distribution Ubuntu, exécutez simplement ldconfig /usr/local/lib (nécessite root) à la fin de make install .

Veuillez appliquer cette solution de contournement rapide pour permettre aux utilisateurs d'Ubuntu d'installer iperf3.

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

Merci d'exécuter ldconfig après que "make install" ait résolu le problème pour moi.

Exécution de Debian 7.8 64Bit (wheezy). Si le problème était prescrit dans le titre, a lancé 'sudo ldconfig' post make install, fonctionnant bien maintenant. Merci pour l'aide dans ce fil.

J'ai dû l'utiliser sur la dernière version (3.1.3) avec ubuntu. Si cela doit être une exigence nécessaire pour toutes les versions d'ubuntu, je suggère que cela vaut la peine de le rendre un peu plus évident afin que l'utilisateur n'ait pas besoin de rechercher google / github pour commencer

Même chose ici avec Ubuntu 16.04 (Xenial Xerus).
ubuntu ferait mieux de faire des signes avant-coureurs à ce sujet à moins que quelqu'un comme moi ne se perde à nouveau ....

Quelqu'un a-t-il un correctif pour l'erreur iperf3 sur Mac OSX? Avec iperf3 3.2, en utilisant le wrapper Python, je vois que libiperf.so.0 est introuvable.

@ jmack51 : Sur mac OS, il n'y aura pas de bibliothèque partagée *.so.0 ... mac OS utilise une extension *.dynlib pour ses bibliothèques partagées. Si "le wrapper Python" fait référence à iperf3-python, c'est un projet séparé et vous devriez probablement le prendre avec eux (je ne sais pas s'il y a un bogue ici ou non).

@ jmack51 : Ah, ne

Merci Bruce, désolé pour le spam, pour l'enregistrement qui est terminé dans https://github.com/thiezn/iperf3-python/issues/23

Je vais rouvrir ce problème, même si je n'ai pas une bonne idée de la façon de le résoudre. Il existe différents cas d'utilisation:

• Systèmes nécessitant l'exécution de ldconfig.
• Les systèmes qui n'ont pas besoin de ldconfig.,
• Les systèmes qui ont besoin de ldconfig avec certains paramètres (par exemple un chemin d'accès).
• Systèmes sans ldconfig (par exemple macOS).
• Compilation croisée.

Je pense à quelque chose comme ce que j'ai proposé le 10 juin 2014, mais en ignorant les conditions d'erreur. Ce serait génial si quelqu'un pouvait commenter le cas de la compilation croisée ... si vous compilez pour une autre plate-forme, faites-vous le plein make install pour mettre en scène les fichiers quelque part ou juste make compile ?

J'ai rencontré ce problème et j'espérais que vous pourriez m'aider à trouver une solution.

J'essaye d'exécuter iperf3 sur mon NAS armv5 QNAP.

J'ai réussi à l'installer. Mais en l'exécutant, j'obtiens ce problème: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (w / ou w / o sudo) ne l'a malheureusement pas corrigé.

[/] # 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 / donne
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*

J'ai essayé d'ajouter /mnt/ext/usr/local/lib à /etc/ld.so.conf et _puis_ d'exécuter ldconfig sans chance.

Voici à quoi il ressemblait avant (et je l'ai à nouveau supprimé depuis):

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

Que puis-je faire / essayer?

@BeyondEvil avez-vous essayé d'utiliser la variable d'environnement LD_LIBRARY_PATH?

@ralcini Non, je ne l'ai pas fait, (je pense). Je vais essayer. 👍

Pour la requête de compilation croisée dans https://github.com/esnet/iperf/issues/153#issuecomment -365012358, j'ai largement utilisé make install . Je suppose que la plupart des systèmes de construction le font également - en particulier si un projet est auto-optimisé.

Je suggérerais que comme premier coup d'œil à cela, le processus de construction d'iperf pourrait envoyer des messages sur la console suggérant la commande à exécuter. Une fois que nous avons cela, passez à le faire réellement.

Existe-t-il une liste des systèmes (* nix) qui ont besoin de ldconfig pour être exécutés, et lesquels ne le font pas? macOS et Windows font partie de la liste des utilisateurs qui ne nécessitent pas l'exécution de ldconfig après make install.

En passant, je suis curieux de savoir quels systèmes n'ont pas besoin de ldconfig pour fonctionner et comment cela est géré.

Fermeture. Ce n'est pas uniquement un problème iperf3, et il semble que personne d'autre n'ait une bonne solution pour cela non plus. (Je dirais qu'une combinaison d'automake et de libtool devrait résoudre ce problème.)

Oui, cela semble être un problème de libtool. La dernière fois que j'ai cherché ça, j'ai trouvé ce qui suit dans le traqueur de bogues GNU:

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

En 1997, commettez 7f9b4e50 pour libtool version 0.6b, la façon de
ldconfig est passé de l'exécution sans "-n" à l'exécution avec "-n".

Sur la base de la discussion qui y a eu lieu, il semble peu probable que cela soit inversé, car tant de temps s'est écoulé et la justification du changement et le risque potentiel de le modifier semblent mal compris. Si quelqu'un rencontre ce problème à l'avenir et veut quand même essayer une solution, c'est probablement aussi proche que vous pourrez le faire correctement.