Iperf: ¿Se necesita ldconfig en make install?

Creado en 21 mar. 2014  ·  27Comentarios  ·  Fuente: esnet/iperf

@lomaxfrog acaba de encontrar un problema en un sistema Ubuntu Linux donde se necesitaba una invocación manual de ldconfig después de make install para que el binario iperf3 encontrara su biblioteca compartida. Esto fue en iperf 3.0.2.

Este problema es para investigar qué pasos deberíamos seguir en este caso. Puede ser un poco complicado porque gran parte del material Makefile se genera automáticamente.

bug

Comentario más útil

Actualización: Alguien (no recuerdo quién era) publicó en el rastreador de problemas de Google Code que vio este problema en Ubuntu Trusty (14.04 LTS). También pude reproducir esto (de alguna manera) en CentOS 6.

El problema parece ser que después de instalar bibliotecas compartidas, el goop Makefile autogenerado ejecuta ldconfig -n /usr/local/lib . Esto reconstruye algunos enlaces simbólicos para las bibliotecas recién instaladas. Sin embargo, de acuerdo con ldconfig (8), -n implica -N , lo que hace que la memoria caché de la biblioteca compartida no se reconstruya, que es exactamente el problema que estamos viendo. Ejecutar ldconfig sin argumentos reconstruye la caché.

Este parece ser un problema de larga data con alguna combinación de automake y libtool ... muchos detalles interesantes (aunque antiguos) aquí:

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

Una sugerencia es agregar algo como esto a src/Makefile.am :

install-exec-hook:
        ldconfig

Todos 27 comentarios

Acabo de probar esto en el código de la punta de la rama maestra iperf3 en CentOS 6. ldconfig fue invocado para mí como parte de "make install" (esto parece ser parte de lo que hace libtool --mode = install), y el iperf3 pudo encontrar su biblioteca compartida inmediatamente después de la instalación, sin necesidad de ldconfig manual. Me pregunto si esto es algo específico de una distribución de Linux.

Otro informe de este problema en otro sistema Ubuntu, los mismos síntomas. Este sistema era: Ubuntu 12.04.3 LTS (GNU / Linux 3.8.0-31-genérico i686).

Me pregunto si ir a un libtool / autoconf / automake más nuevo ayudaría con este problema.

De acuerdo, pude reproducir esto en una máquina virtual de Ubuntu (12.04 LTS, que por supuesto desarrollé el mismo día en que salió 14.04 LTS). Todavía se agita un poco en Ubuntu, por lo que todavía no he llegado tan lejos con una solución.

También se necesitaba ejecutar ldconfig en Debian Wheezy (7.5) de 64 bits. Salud,

Actualización: Alguien (no recuerdo quién era) publicó en el rastreador de problemas de Google Code que vio este problema en Ubuntu Trusty (14.04 LTS). También pude reproducir esto (de alguna manera) en CentOS 6.

El problema parece ser que después de instalar bibliotecas compartidas, el goop Makefile autogenerado ejecuta ldconfig -n /usr/local/lib . Esto reconstruye algunos enlaces simbólicos para las bibliotecas recién instaladas. Sin embargo, de acuerdo con ldconfig (8), -n implica -N , lo que hace que la memoria caché de la biblioteca compartida no se reconstruya, que es exactamente el problema que estamos viendo. Ejecutar ldconfig sin argumentos reconstruye la caché.

Este parece ser un problema de larga data con alguna combinación de automake y libtool ... muchos detalles interesantes (aunque antiguos) aquí:

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

Una sugerencia es agregar algo como esto a src/Makefile.am :

install-exec-hook:
        ldconfig

Esto parece haber solucionado el problema ... probado con make install seguido inmediatamente por la invocación de iperf3 en CentOS 6 y Ubuntu 12.04 LTS.

Esto ha causado algunos problemas con las personas que intentan instalar como un usuario no root (los casos de uso son la instalación en una jerarquía de directorios privados o la creación de un RPM como un usuario no root). Básicamente, ldconfig como se invoca no quiere ejecutarse como no root porque no tendría suficientes permisos de archivo.

Quizás la invocación de ldconfig debería cambiarse para hacer algo como:

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

Reabriendo este problema para intentarlo de nuevo.

Esto no funciona en MacOS, que no usa ldconfig y, de hecho, causa errores en esa plataforma.

Apuntando a este error para 3.1. De una forma u otra, necesitamos tener algún tipo de resolución para esto, incluso si solo tiene el elemento en la sección de problemas conocidos.

Este es realmente un problema de instalación de software genérico. No lo vamos a resolver aquí, dadas las dificultades para hacerlo en múltiples plataformas. Cierre sin solución.

Si desea ceñirse a /usr/local/lib lugar de /usr/lib32 en la distribución de Ubuntu, simplemente ejecute ldconfig /usr/local/lib (requiere root) al final de make install .

Aplique esta solución rápida para permitir que los usuarios de Ubuntu instalen iperf3.

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

Gracias por ejecutar ldconfig después de que "make install" resolviera el problema.

Ejecutando Debian 7.8 64Bit (sibilancia). Tenía el problema según lo prescrito en el título, ejecuté 'sudo ldconfig' post make install, funcionando bien ahora. Gracias por la ayuda en este hilo.

Tuve que usar esto en la última versión (3.1.3) con ubuntu. Si este es un requisito necesario para todas las versiones de ubuntu, sugiero que vale la pena hacerlo un poco más obvio para que el usuario no necesite buscar en google / github para comenzar.

Lo mismo aquí con Ubuntu 16.04 (Xenial Xerus).
Es mejor que ubuntu haga señales de advertencia sobre esto a menos que alguien como yo se pierda de nuevo ...

¿Alguien tiene una solución para el error iperf3 en Mac OSX? Con iperf3 3.2, usando el contenedor de Python, veo que no se encuentra libiperf.so.0.

@ jmack51 : En mac OS, no habrá una biblioteca compartida *.so.0 ... mac OS usa una extensión *.dynlib para sus bibliotecas compartidas. Si "la envoltura de Python" se refiere a iperf3-python, ese es un proyecto separado y probablemente debería abordar esto con ellos (no estoy seguro de si hay un error aquí o no).

@ jmack51 : Ah, indiferencia, veo dónde ya abriste un problema con thiezn / iperf3-python.

Gracias Bruce, perdón por el spam, por el registro que se terminó en https://github.com/thiezn/iperf3-python/issues/23

Voy a volver a abrir este problema, aunque no tengo una gran idea sobre cómo solucionarlo. Hay varios casos de uso:

  • Sistemas que necesitan ldconfig para ejecutarse.
  • Sistemas que no necesitan ldconfig.,
  • Sistemas que necesitan ldconfig con algunos parámetros (por ejemplo, un nombre de ruta).
  • Sistemas sin ldconfig (por ejemplo, macOS).
  • Compilación cruzada.

Estoy pensando en algo como lo que propuse el 10 de junio de 2014, pero ignorando las condiciones de error. Sería genial si alguien pudiera comentar sobre el caso de compilación cruzada ... si está compilando para otra plataforma, ¿hace el make install completo para organizar los archivos en algún lugar o simplemente make compile ?

Me encontré con este problema y esperaba que pudiera ayudarme a encontrar una solución.

Estoy intentando ejecutar iperf3 en mi NAS de QNAP armv5.

Logré instalarlo. Pero al ejecutarlo, me sale este problema: iperf3: error while loading shared libraries: libiperf.so.0: cannot open shared object file: No such file or directory

ldconfig (w / o w / o sudo) no lo solucionó desafortunadamente.

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

Intenté agregar /mnt/ext/usr/local/lib a /etc/ld.so.conf y _entonces_ ejecutar ldconfig sin suerte.

Así es como se veía antes (y desde entonces lo he eliminado de nuevo):

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

¿Qué puedo hacer / probar?

@BeyondEvil, ¿ ha intentado utilizar la variable de entorno LD_LIBRARY_PATH?

@ralcini No, no lo he hecho, (creo). Lo probaré. 👍

Para la consulta de compilación cruzada en https://github.com/esnet/iperf/issues/153#issuecomment -365012358, he usado make install extensamente. Supongo que la mayoría de los sistemas de compilación también lo hacen, especialmente si un proyecto tiene herramientas automáticas.

Sugeriría como primer intento de hacer esto, el proceso de compilación de iperf podría enviar mensajes a la consola sugiriendo el comando que debería ejecutarse. Una vez que tengamos eso, pasemos a hacerlo.

¿Hay una lista de qué sistemas (* nix) necesitan ldconfig para ejecutarse y cuáles no? macOS y Windows caen en la lista de los que no requieren que ldconfig se ejecute después de realizar la instalación.

Aparte, tengo curiosidad por saber qué sistemas no necesitan ldconfig para ejecutarse y cómo se gestiona.

Clausura. Este no es solo un problema de iperf3, y parece que nadie más tiene una buena solución tampoco. (Yo diría que alguna combinación de automake y libtool debería estar lidiando con este problema).

Sí, parece un problema de libtool. La última vez que fui a perseguir esto, encontré lo siguiente en el rastreador de errores de GNU:

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

En 1997, confirme 7f9b4e50 para libtool versión 0.6b, la forma de ejecutar
ldconfig se cambió de ejecutarse sin "-n" a ejecutarse con "-n".

Según la discusión allí, parece poco probable que esto se revierta, ya que ha pasado tanto tiempo y la justificación del cambio y el riesgo potencial de volver a cambiarlo parecen no comprenderse bien. Si alguien se encuentra con este problema en el futuro y quiere intentar solucionarlo de todos modos, probablemente sea lo más cerca que estará de hacerlo correctamente.

¿Fue útil esta página
0 / 5 - 0 calificaciones