¿Por qué Python no puede encontrar objetos compartidos que estén en directorios en sys.path?

shared-libraries libcurl

Question

Estoy tratando de importar pycurl:

$ python -c "import pycurl"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: libcurl.so.4: cannot open shared object file: No such file or directory

Ahora, libcurl.so.4 está en / usr / local / lib. Como puede ver, esto está en sys.path:

$ python -c "import sys; print sys.path"
['''', ''/usr/local/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg'', 
''/usr/local/lib/python25.zip'', ''/usr/local/lib/python2.5'', 
''/usr/local/lib/python2.5/plat-linux2'', ''/usr/local/lib/python2.5/lib-tk'', 
''/usr/local/lib/python2.5/lib-dynload'', 
''/usr/local/lib/python2.5/sitepackages'', ''/usr/local/lib'', 
''/usr/local/lib/python2.5/site-packages'']

Cualquier ayuda será apreciada.

Answer 1

Asegúrese de que su módulo libcurl.so esté en la ruta de acceso de la biblioteca del sistema, que es distinta y separada de la ruta de la biblioteca de python.

Una "solución rápida" es agregar esta ruta a una variable LD_LIBRARY_PATH. Sin embargo, configurar ese sistema (o incluso toda la cuenta) es una IDEA MALA, ya que es posible configurarlo de tal manera que algunos programas encuentren una biblioteca que no debería, o incluso peor, abrir agujeros de seguridad.

Si sus "bibliotecas instaladas localmente" están instaladas en, por ejemplo, / usr / local / lib, agregue este directorio a /etc/ld.so.conf (es un archivo de texto) y ejecute "ldconfig"

El comando ejecutará una utilidad de almacenamiento en caché, pero también creará todos los "enlaces simbólicos" necesarios para que funcione el sistema cargador. Es sorprendente que la "instalación de make" para libcurl no haya hecho esto, pero es posible que no pueda si / usr / local / lib ya no está en /etc/ld.so.conf.

PD: es posible que tu /etc/ld.so.conf no contenga nada más que "include ld.so.conf.d / *. Conf". Todavía puede agregar una ruta de directorio después de ella, o simplemente crear un nuevo archivo dentro del directorio desde el que se está incluyendo. No te olvides de ejecutar "ldconfig" después de él.

Ten cuidado. Hacer esto mal puede arruinar su sistema.

Además: asegúrese de que su módulo python esté compilado contra esa versión de libcurl. Si acaba de copiar algunos archivos desde otro sistema, esto no siempre funcionará. En caso de duda, compile sus módulos en el sistema en el que desea ejecutarlos.

Answer 2

Como complemento de las respuestas anteriores, estoy tropezando con un problema similar y estoy trabajando completamente con la versión predeterminada de python.

Cuando llamo al ejemplo de la biblioteca de objetos compartidos que estoy buscando con LD_LIBRARY_PATH , obtengo algo como esto:

$ LD_LIBRARY_PATH=/path/to/mysodir:$LD_LIBRARY_PATH python example-so-user.py
python: can''t open file ''example-so-user.py'': [Errno 2] No such file or directory

Cabe destacar que ni siquiera se queja de la importación, ¡se queja del archivo fuente!

Pero si LD_PRELOAD la carga del objeto usando LD_PRELOAD :

$ LD_PRELOAD=/path/to/mysodir/mypyobj.so python example-so-user.py
python: error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory

... Inmediatamente recibo un mensaje de error más significativo: ¡sobre una dependencia faltante!

Solo pensé en anotar esto aquí. ¡Salud!

Answer 3

También puede establecer LD_RUN_PATH en / usr / local / lib en su entorno de usuario cuando compila pycurl en primer lugar. Esto insertará / usr / local / lib en el atributo RPATH del módulo de extensión .so para que sepa automáticamente dónde encontrar la biblioteca en tiempo de ejecución sin tener que establecer LD_LIBRARY_PATH en tiempo de ejecución.

Answer 4

Tenía exactamente el mismo problema. Instalé curl 7.19 en / opt / curl / para asegurarme de que no afectaría el curl actual en nuestros servidores de producción. Una vez que vinculé libcurl.so.4 a / usr / lib:

sudo ln -s /opt/curl/lib/libcurl.so /usr/lib/libcurl.so.4

Todavía tengo el mismo error! Durf.

Pero ejecutar ldconfig hace el enlace para mí y funcionó. No es necesario establecer LD_RUN_PATH o LD_LIBRARY_PATH en absoluto. Solo necesitaba ejecutar ldconfig.

Answer 5

Utilizo python setup.py build_ext -R/usr/local/lib -I/usr/local/include/libcalg-1.0 y el archivo .so compilado está bajo la carpeta de compilación. puede escribir python setup.py --help build_ext para ver las explicaciones de -R y -I

Answer 6

sys.path solo se busca módulos de Python. Para las bibliotecas vinculadas dinámicas, las rutas buscadas deben estar en LD_LIBRARY_PATH . Compruebe si su LD_LIBRARY_PATH incluye /usr/local/lib , y si no lo tiene, agréguelo e intente de nuevo.

Algo más de información ( source ):

En Linux, la variable de entorno LD_LIBRARY_PATH es un conjunto de directorios separados por dos puntos donde se deben buscar primero las bibliotecas, antes del conjunto estándar de directorios; esto es útil al depurar una nueva biblioteca o usar una biblioteca no estándar para fines especiales. La variable de entorno LD_PRELOAD enumera bibliotecas compartidas con funciones que anulan el conjunto estándar, al igual que /etc/ld.so.preload. Estos son implementados por el cargador /lib/ld-linux.so. Debo señalar que, aunque LD_LIBRARY_PATH funciona en muchos sistemas tipo Unix, no funciona en todos; por ejemplo, esta funcionalidad está disponible en HP-UX pero como la variable de entorno SHLIB_PATH, y en AIX, esta funcionalidad es a través de la variable LIBPATH (con la misma sintaxis, una lista separada por dos puntos).

Actualización: para establecer LD_LIBRARY_PATH , use una de las siguientes opciones, idealmente en su ~/.bashrc o archivo equivalente:

export LD_LIBRARY_PATH=/usr/local/lib

o

export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

Utilice la primera forma si está vacía (equivalente a la cadena vacía, o no está presente en absoluto), y la segunda si no lo está. Tenga en cuenta el uso de la exportación .