Iperf: ldconfig benötigt in make install?

Ich habe dies gerade anhand von Code aus der Spitze des iperf3-Hauptzweigs unter CentOS 6 getestet. Ldconfig wurde für mich als Teil von "make install" aufgerufen (dies scheint ein Teil dessen zu sein, was von libtool --mode = install gemacht wird). und der iperf3 konnte seine gemeinsam genutzte Bibliothek sofort nach der Installation finden, ohne dass eine manuelle ldconfig erforderlich war. Ich frage mich, ob dies etwas ist, das für eine Linux-Distribution spezifisch ist.

Ein weiterer Bericht über dieses Problem auf einem anderen Ubuntu-System, die gleichen Symptome. Dieses System war: Ubuntu 12.04.3 LTS (GNU / Linux 3.8.0-31-generic i686).

Ich frage mich, ob ein Wechsel zu einem neueren libtool / autoconf / automake dieses Problem lösen würde.

OK, ich konnte dies auf einer Ubuntu-VM reproduzieren (12.04 LTS, die ich natürlich noch am selben Tag aufgebaut habe, an dem 14.04 LTS herauskam). Immer noch ein bisschen auf Ubuntu herumwirbeln, also bin ich mit einer Lösung noch nicht so weit gekommen.

Das Ausführen von ldconfig wurde auch für Debian Wheezy (7.5) 64bit benötigt. Prost,

Update: Jemand (ich vergesse, wer es war) hat im Google Code Issue Tracker gepostet, dass er dieses Problem unter Ubuntu Trusty (14.04 LTS) gesehen hat. Ich konnte dies auch (auf eine Art und Weise) auf CentOS 6 reproduzieren.

Das Problem scheint zu sein, dass nach der Installation gemeinsam genutzter Bibliotheken auf dem automatisch generierten Makefile-Goop ldconfig -n /usr/local/lib . Dadurch werden einige Symlinks für die neu installierten Bibliotheken neu erstellt. Laut ldconfig (8) impliziert -n -N , was dazu führt, dass der Cache der gemeinsam genutzten Bibliothek nicht neu erstellt wird. Dies ist genau das Problem, das wir sehen. Wenn Sie ldconfig ohne Argumente ausführen, wird der Cache neu erstellt.

Dies scheint ein langjähriges Problem mit einer Kombination aus Automake und Libtool zu sein ... viele interessante (wenn auch alte) Details hier:

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

Ein Vorschlag ist, src/Makefile.am etwas hinzuzufügen:

install-exec-hook:
        ldconfig

Dies scheint das Problem behoben zu haben ... getestet mit make install unmittelbar gefolgt von einem iperf3-Aufruf unter CentOS 6 und Ubuntu 12.04 LTS.

Dies hat einige Probleme bei Personen verursacht, die versuchen, als Nicht-Root-Benutzer zu installieren (Anwendungsfälle sind die Installation in einer privaten Verzeichnishierarchie oder das Erstellen eines RPM als Nicht-Root-Benutzer). Grundsätzlich möchte ldconfig als aufgerufen nicht als Nicht-Root ausgeführt werden, da ihm ausreichende Dateiberechtigungen fehlen würden.

Möglicherweise sollte der ldconfig-Aufruf geändert werden, um Folgendes zu tun:

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

Öffnen Sie dieses Problem erneut, um es erneut zu versuchen.

Dies funktioniert nicht unter MacOS, das ldconfig nicht verwendet, und verursacht tatsächlich Fehler auf dieser Plattform.

Targeting dieses Fehlers für 3.1. Auf die eine oder andere Weise brauchen wir eine Lösung dafür, auch wenn es nur das Element im Abschnitt über bekannte Probleme gibt.

Dies ist wirklich ein generisches Problem bei der Softwareinstallation. Wir werden es hier nicht lösen, da dies auf mehreren Plattformen schwierig ist. Schließen ohne Fix.

Wenn Sie in der Ubuntu-Distribution bei /usr/local/lib statt /usr/lib32 bleiben möchten, führen Sie einfach ldconfig /usr/local/lib (erfordert root) am Ende von make install .

Wenden Sie diese schnelle Problemumgehung an, damit Ubuntu-Benutzer iperf3 installieren können.

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

Vielen Dank, dass Sie ldconfig ausgeführt haben, nachdem "make install" das Problem für mich gelöst hat.

Ausführen von Debian 7.8 64Bit (keuchend). Hatte das Problem wie im Titel vorgeschrieben, lief 'sudo ldconfig' post make install und funktionierte jetzt einwandfrei. Danke für die Hilfe in diesem Thread.

Musste dies auf der neuesten Version (3.1.3) mit Ubuntu verwenden. Wenn dies eine notwendige Voraussetzung für alle Ubuntu-Versionen sein soll, empfehle ich, dass es sich lohnt, es ein bisschen offensichtlicher zu machen, damit der Benutzer nicht nach Google / Github suchen muss, um loszulegen

Gleiches gilt hier für Ubuntu 16.04 (Xenial Xerus).
Ubuntu machen besser Warnzeichen darüber, es sei denn, jemand wie ich geht wieder verloren ....

Hat jemand eine Lösung für den iperf3-Fehler unter Mac OS X? Mit iperf3 3.2, das den Python-Wrapper verwendet, wird libiperf.so.0 nicht gefunden.

@ jmack51 : Unter Mac OS gibt es keine gemeinsam genutzte Bibliothek *.so.0 ... Mac OS verwendet für seine gemeinsam genutzten Bibliotheken eine Erweiterung *.dynlib . Wenn sich "der Python-Wrapper" auf iperf3-python bezieht, handelt es sich um ein separates Projekt, und Sie sollten dies wahrscheinlich mit ihnen aufnehmen (ich bin mir nicht sicher, ob hier ein Fehler vorliegt oder nicht).

@ jmack51 : Ah, ignoriere, ich sehe, wo du bereits ein Problem mit thiezn / iperf3-python geöffnet hast.

Vielen Dank, Bruce, entschuldige den Spam für die Aufzeichnung, die in https://github.com/thiezn/iperf3-python/issues/23 beendet ist

Ich werde dieses Problem erneut öffnen, obwohl ich keine gute Idee habe, wie ich es beheben kann. Es gibt verschiedene Anwendungsfälle:

• Systeme, auf denen ldconfig ausgeführt werden muss.
• Systeme, die ldconfig nicht benötigen.,
• Systeme, die ldconfig mit einigen Parametern benötigen (z. B. einem Pfadnamen).
• Systeme ohne ldconfig (zB macOS).
• Cross-Compiling.

Ich denke an etwas, was ich am 10. Juni 2014 vorgeschlagen habe, ignoriere aber die Fehlerbedingungen. Es wäre großartig, wenn jemand den Cross-Compiling-Fall kommentieren könnte ... Wenn Sie für eine andere Plattform Cross-Compilieren, tun Sie das volle make install , um die Dateien irgendwo oder nur make compile zu inszenieren

Ich bin auf dieses Problem gestoßen und hatte gehofft, Sie könnten mir helfen, eine Lösung zu finden.

Ich versuche, iperf3 auf meinem armv5 QNAP NAS auszuführen.

Ich habe es geschafft, es zu installieren. Aber wenn ich es laufen lasse, bekomme ich dieses Problem: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (ohne oder ohne Sudo) hat das Problem leider nicht behoben.

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

Ich habe versucht, /mnt/ext/usr/local/lib zu /etc/ld.so.conf hinzuzufügen und dann ldconfig ohne Glück auszuführen.

So sah es vorher aus (und ich habe es seitdem wieder entfernt):

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

Was kann ich tun / versuchen?

@BeyondEvil Haben Sie versucht, die Umgebungsvariable LD_LIBRARY_PATH zu verwenden?

@ralcini Nein, habe ich nicht (glaube ich). Ich werde es versuchen. 👍

Für die Cross-Compiling-Abfrage in https://github.com/esnet/iperf/issues/153#issuecomment -365012358 habe ich make install ausgiebig verwendet. Ich würde vermuten, dass die meisten Build-Systeme dies auch tun - insbesondere, wenn ein Projekt autotoolisiert ist.

Ich würde als ersten Versuch vorschlagen, dass der iperf-Erstellungsprozess Nachrichten auf der Konsole ausgeben könnte, die den Befehl vorschlagen, der ausgeführt werden sollte. Sobald wir das haben, gehen Sie dazu über, es tatsächlich zu tun.

Gibt es eine Liste, welche (* nix) Systeme ldconfig benötigen, um ausgeführt zu werden, und welche nicht? macOS und Windows fallen in die Liste, dass ldconfig nach der make-Installation nicht ausgeführt werden muss.

Abgesehen davon bin ich gespannt, auf welchen Systemen ldconfig nicht ausgeführt werden muss und wie dies verwaltet wird.

Schließen. Dies ist nicht nur ein iperf3-Problem, und es scheint, als hätte auch niemand eine gute Lösung dafür. (Ich würde davon ausgehen, dass sich eine Kombination aus automake und libtool mit diesem Problem befassen sollte.)

Ja, es scheint ein Libtool-Problem zu sein. Als ich dies das letzte Mal verfolgte, fand ich im GNU-Bug-Tracker Folgendes:

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

Im Jahr 1997 Commit 7f9b4e50 für Libtool Version 0.6b, die Art zu laufen
ldconfig wurde von "ohne" -n "in" mit "-n" geändert.

Aufgrund der dortigen Diskussion ist es unwahrscheinlich, dass dies rückgängig gemacht wird, da so viel Zeit vergangen ist und die Gründe für die Änderung und das Risikopotenzial einer Rückänderung kaum verstanden werden. Wenn jemand in Zukunft auf dieses Problem stößt und trotzdem nach einer Lösung suchen möchte, ist dies wahrscheinlich so nah, wie Sie es richtig machen können.