El ejecutable de Python no encuentra la biblioteca compartida libpython

143

Estoy instalando Python 2.7 en CentOS 5. Construí e instalé Python de la siguiente manera

./configure --enable-shared --prefix=/usr/local
make
make install

Cuando intento ejecutar / usr / local / bin / python, recibo este mensaje de error

/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

Cuando ejecuto ldd en / usr / local / bin / python, obtengo

ldd /usr/local/bin/python
    libpython2.7.so.1.0 => not found
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e9a00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000030e9200000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00000030fa200000)
    libm.so.6 => /lib64/libm.so.6 (0x00000030e9600000)
    libc.so.6 => /lib64/libc.so.6 (0x00000030e8e00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000030e8a00000)

¿Cómo le digo a Python dónde encontrar libpython?

sans
fuente

Respuestas:

204

Intenta lo siguiente:

LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python

Reemplácela /usr/local/libcon la carpeta donde la instaló libpython2.7.so.1.0si no está en ella /usr/local/lib.

Si esto funciona y desea que los cambios sean permanentes, tiene dos opciones:

  1. Agregue export LD_LIBRARY_PATH=/usr/local/liba su .profileen su directorio de inicio (esto funciona solo si está utilizando un shell que carga este archivo cuando se inicia una nueva instancia de shell). Esta configuración afectará solo a su usuario.

  2. Añadir /usr/local/liba /etc/ld.so.confy correr ldconfig. Esta es una configuración de todo el sistema, por supuesto.

Tamás
fuente
¿Hay alguna forma de exportarlo para que funcione con eclipse? Lo agregué a mi .profile, sin embargo, Eclipse no puede iniciar gdb. (Nota: sin embargo, agregarlo a ld.so.conf funciona)
Setheron
así que verifiqué las variables de entorno con las que se ejecuta eclipse y tiene el LD_LIBRARY_PATH adecuado. ¡Creo que cuando lanza GDB no usa ningún shell y, por lo tanto, no obtiene ninguna variable de entorno! La configuración de libpython en la configuración de depuración tampoco ayudó, ya que eso es solo para cuando gdb realmente se carga (pero necesito la lib para que gdb se cargue)
Setheron
1
¿Puede depurar la aplicación con éxito cuando se ejecuta gdbdesde la línea de comandos y LD_LIBRARY_PATH está configurado correctamente en el terminal? De lo contrario, probablemente tendrá que configurar LD_LIBRARY_PATH en su .gdbinitarchivo. Consulte esta respuesta para obtener más información: stackoverflow.com/a/7041845/156771
Tamás
Necesito el LD_LIBRARY_PATH para iniciar gdb (python libs), no para la depuración real de mi aplicación. Hasta ahora solo he logrado solucionarlo configurándolo en ldconfig. Sin embargo, puedo depurar la aplicación a través de CLI porque recogerá el LD_LIBRARY_PATH de mi archivo ZSHRC.
Setheron
10
Solo una nota para cualquiera que intente esto: es solo "/ usr / local / lib", y no una "inclusión" inicial como el original "include ld.so.conf.d / *. Conf".
timss
79

Poniéndome el sombrero de sepulturero ...

La mejor manera que he encontrado para abordar esto es en tiempo de compilación. Dado que usted es el prefijo de configuración de todos modos, también podría decirle al ejecutable explícitamente dónde encontrar sus bibliotecas compartidas. A diferencia de OpenSSL y otros paquetes de software, Python no le brinda directivas de configuración agradables para manejar rutas alternativas de la biblioteca (no todos son root, ya sabe ...) En el caso más simple, todo lo que necesita es lo siguiente:

./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-Wl,--rpath=/usr/local/lib"

O si prefiere la versión no Linux:

./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-R/usr/local/lib"

La rpathbandera " " le dice a Python que tiene bibliotecas de tiempo de ejecución que necesita en esa ruta en particular. Puede llevar esta idea más allá para manejar las dependencias instaladas en una ubicación diferente a las ubicaciones estándar del sistema. Por ejemplo, en mis sistemas, dado que no tengo acceso a la raíz y necesito realizar instalaciones de Python casi completamente independientes, mi línea de configuración se ve así:

./configure --enable-shared \
            --with-system-ffi \
            --with-system-expat \
            --enable-unicode=ucs4 \
            --prefix=/apps/python-${PYTHON_VERSION} \
            LDFLAGS="-L/apps/python-${PYTHON_VERSION}/extlib/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/extlib/lib" \
            CPPFLAGS="-I/apps/python-${PYTHON_VERSION}/extlib/include"

En este caso soy compilar las bibliotecas que utiliza Python (como ffi, readline, etc.) en un extlibdirectorio dentro de la pitón propio árbol de directorios. De esta forma, puedo usar el directorio python - $ {PYTHON_VERSION} y aterrizar en cualquier lugar y "funcionará" (siempre que no te encuentres libco tengas libmconflictos). Esto también ayuda cuando intentas ejecutar varias versiones de Python en el mismo cuadro, ya que no necesitas seguir cambiando LD_LIBRARY_PATHo preocuparte por elegir la versión incorrecta de la biblioteca de Python.

Editar: Olvidé mencionar que la compilación se quejará si no configura la PYTHONPATHvariable de entorno a lo que usa como prefijo y no compila algunos módulos, por ejemplo, para ampliar el ejemplo anterior, configure PYTHONPATHel prefijo utilizado en el anterior ejemplo con export PYTHONPATH=/apps/python-${PYTHON_VERSION}...

Foosh
fuente
//, Esto se parece a lo que estoy buscando. ¿Dónde puedo encontrar más información sobre las formas de "tar el directorio de la versión de python y aterrizar en cualquier lugar y" funcionará "(siempre que no se encuentre con libc o conflictos de libm)" ? ¿Crees que vale la pena hacer una pregunta separada de stackoverflow.com a partir de esto?
Nathan Basanese
// Además, ¿cómo se debe configurar $PYTHON_VERSION?
Nathan Basanese
//, configuro $PYTHON_VERSIONdespués de configurar. Sin $PYTHON_VERSIONembargo, incluso con el set, el compilador se quejaPython build finished successfully! The necessary bits to build these optional modules were not found: _bz2 _curses _curses_panel _gdbm _lzma _sqlite3 _tkinter readline
Nathan Basanese
//, ¿Requiere esto alguna modificación al makecomando y otros comandos de instalación?
Nathan Basanese
1
@NathanBasanese en el caso de los desaparecidos bz2, maldiciones, gdbm lzma, etc lo que se necesita para compilar cada uno de los primero con un prefijo de /apps/python-${PYTHON_VERSION}/extlibasegurar sus bibliotecas y cabeceras están en la ubicación adecuada para el proceso de composición del pitón de encontrar. En cuanto a los paquetes a nivel de sistema, probablemente se quedará atrapado confiando en un usuario root para que los instale de antemano. O encontrar una alternativa que se pueda compilar y aterrizar en elextlib
Foosh
21

Tuve el mismo problema y lo resolví de esta manera:

Si sabe dónde reside libpython, supuse que sería /usr/local/lib/libpython2.7.so.1.0en su caso, simplemente puede crear un enlace simbólico:

sudo ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib/libpython2.7.so.1.0

Luego intente ejecutar lddnuevamente y vea si funcionó.

Omer Dagan
fuente
6

Instalé Python 3.5 de Software Collections en CentOS 7 minimal. Todo funcionó bien por sí solo, pero vi el error de biblioteca compartida mencionado en esta pregunta cuando intenté ejecutar un script CGI simple:

tail /var/log/httpd/error_log
AH01215: /opt/rh/rh-python35/root/usr/bin/python: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory

Quería una solución permanente para todo el sistema que funcionara para todos los usuarios, por lo que excluía agregar declaraciones de exportación a archivos .profile o .bashrc. Existe una solución de una línea, basada en la página de soluciones de Red Hat . Gracias por el comentario que lo señala:

echo 'source scl_source enable rh-python35' | sudo tee --append /etc/profile.d/python35.sh

Después de un reinicio, todo está bien en el shell, pero a veces mi servidor web todavía se queja. Hay otro enfoque que siempre funcionó tanto para el shell como para el servidor, y es más genérico. ¡Vi la solución aquí y luego me di cuenta de que en realidad también se menciona en una de las respuestas! De todos modos, en CentOS 7, estos son los pasos:

 vim /etc/ld.so.conf

Que en mi máquina acaba de tener:

include ld.so.conf.d/*.conf

Entonces creé un nuevo archivo:

vim /etc/ld.so.conf.d/rh-python35.conf

Y agregado:

/opt/rh/rh-python35/root/usr/lib64/

Y para reconstruir manualmente el caché:

sudo ldconfig

Eso es todo, ¡los guiones funcionan bien!

Esta fue una solución temporal, que no funcionó en los reinicios:

sudo ldconfig /opt/rh/rh-python35/root/usr/lib64/ -v

La opción -v (detallada) era solo para ver lo que estaba sucediendo. Vi que sí: / opt / rh / rh-python35 / root / usr / lib64: libpython3.so.rh-python35 -> libpython3.so.rh-python35 libpython3.5m.so.rh-python35-1.0 -> libpython3.5m.so.rh-python35-1.0

Este error en particular desapareció. Por cierto, tuve que hacer que chownel usuario apache para deshacerse de un error de permiso después de eso.

Tenga en cuenta que solía encontrar para ubicar el directorio de la biblioteca. También puedes hacer:

sudo yum install mlocate
sudo updatedb
locate libpython3.5m.so.rh-python35-1.0

Que en mi VM devuelve:

/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0

Cuál es el camino que necesito dar a ldconfig, como se muestra arriba.

Nagev
fuente
1
Podría haberse ahorrado algunos problemas yendo a /etc/profile.d y creando un archivo con lo siguiente: #!/bin/bashy source scl_source enable rh-python35en él. access.redhat.com/solutions/527703
Doug
2

En Solaris 11

Úselo LD_LIBRARY_PATH_64para resolver el enlace simbólico a las bibliotecas de Python.

En mi caso para python3.6 LD_LIBRARY_PATHno funcionó, pero lo LD_LIBRARY_PATH_64hizo.

Espero que esto ayude.
Saludos

basy
fuente
1

Esto funcionó para mí ...

$ sudo apt-get install python2.7-dev
Kyle Anderson
fuente
Hola, esta no es la solución correcta, porque después de esto, su binario personalizado de Python de compilación está usando el .so del que instaló desde apt-get. Esto puede causar problemas mientras tengan la misma versión, o si modificó el código fuente de Python, no tomará esfuerzos.
Azusa Nakano
0

Lo instalé usando el comando:

./configure --prefix=/usr       \
            --enable-shared     \
            --with-system-expat \
            --with-system-ffi   \
            --enable-unicode=ucs4 &&

make

Ahora, como usuario root:

make install &&
chmod -v 755 /usr/lib/libpython2.7.so.1.0

Luego intenté ejecutar python y obtuve el error:

/ usr / local / bin / python: error al cargar las bibliotecas compartidas: libpython2.7.so.1.0: no se puede abrir el archivo de objeto compartido: No existe tal archivo o directorio

Luego, me desconecté del usuario root y nuevamente intenté ejecutar Python y funcionó con éxito.

Pankaj
fuente
0

Todo lo que necesita es la instalación de los archivos de desarrollo libpython [3 o 2].


fuente
-1

solo instala python-lib. (python27-lib). Instalará libpython2.7.so1.0. No necesitamos configurar nada manualmente.

chintan-p-bhatt
fuente
44
//, y si estás en, por ejemplo, CEntOS 6.3? Esto no funciona, allí, y generalmente la gente está compilando Python para tratar un caso en el que el sistema Python es una versión extraña, rota, poco confiable o algún otro deseo de no tocar el sistema en general.
Nathan Basanese