Coredump al compilar Python con una versión OpenSL personalizada

Question

Mar 14, 2014, 04:19 PM

Coredump al compilar Python con una versión OpenSL personalizada

Al compilar python-3.4.0rc3 con una instalación compartida local openssl-1.0.1f,make no imprime ningún error, pero luego obtengo el siguiente volcado de núcleo en make install o make test:

Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0  0x00007f131dd10510 in EVP_PKEY_CTX_dup () from /data2/soft/openssl/lib/libcrypto.so.1.0.0
#1  0x00007f131dd0284f in EVP_MD_CTX_copy_ex () from /data2/soft/openssl/lib/libcrypto.so.1.0.0
#2  0x00007f131e256ab5 in EVPnew (name_obj=0x7f131e46a500, digest=0x0, initial_ctx=0x7f131e459a40, cp=0x0, len=0) at /data2/soft/python3/Python-3.4.0rc3/Modules/_hashopenssl.c:410
#3  0x00007f131e25726e in EVP_new_md5 (self=<value optimized out>, args=<value optimized out>) at /data2/soft/python3/Python-3.4.0rc3/Modules/_hashopenssl.c:799
#4  0x00000000004c7eef in ?? ()

Aquí está la lista completa de comandos utilizados

tar -axf Python-3.4.0rc3.tgz
cd Python-3*
# For lzma and a pip-compatible openssl
export CFLAGS='-I/data2/soft/openssl/include/openssl -I/data2/local/include/'
export LDFLAGS='-L/data2/soft/openssl/lib -L/data2/local/lib/'
export LD_LIBRARY_PATH="/data2/soft/openssl/lib:/data2/local/lib/:$LD_LIBRARY_PATH"
# Ready !
./configure --prefix=/data2/soft/python3
make
make install

Notas:

El sistema operativo es SUSE Linux Enterprise Server 11 (x86_64)apuntando a Python a una ubicación personalizada para la biblioteca lzma ubicada enopenssl fue construido con./config shared --openssldir=/data2/soft/opensslopensslmake test huellas dactilaresTODAS LAS PRUEBAS SON EXITOSAS.sin el personalizado openssl * FLAGS, make install se realiza correctamente y obtengo estos resultados para make test:71 tests OK. tests failed: test_cmd_line test_gdb test_smtpnet test_ssl

¿Cómo puedo solucionar esto, o al menos investigar lo que está pasando?

Edición 1--5:

Las bibliotecas compartidas se generaron correctamente:

> ls /data2/soft/openssl/lib
drwxr-xr-x engines
-rw-r--r-- libcrypto.a
lrwxrwxrwx libcrypto.so -> libcrypto.so.1.0.0
-r-xr-xr-x libcrypto.so.1.0.0
-rw-r--r-- libssl.a
lrwxrwxrwx libssl.so -> libssl.so.1.0.0
-r-xr-xr-x libssl.so.1.0.0
drwxr-xr-x pkgconfig

Así que cambié esto en Configuración:

SSL=/data2/soft/openssl/
_ssl _ssl.c \                               
    -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
    $(SSL)/lib/libssl.a $(SSL)/lib/libcrypto.a -ldl

Y cambié de nuevo LDFLAGS / CFLAGS en consecuencia. Pero todavía hay un -lssl cuando ejecuto make clean && make, debido al módulo _hashopen:

gcc -pthread -shared -L/data2/local/lib/ -L/data2/local/lib/ -L/data2/local/lib/ -I/data2/local/include/ build/temp.linux-x86_64-3.4/data2/soft/python3/Python-3.4.0rc3/Modules/_hashopenssl.o -L/data2/local/lib/ -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-3.4/_hashlib.cpython-34m.so

Supongo que es el que está causando los núcleos, porque todavía están allí ... Intenté agregar cosas similares al archivo de instalación, pero no hay ningún elemento comentado para este y crearlo causa otra falla más críptica:

gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.4m.a -lpthread -ldl  -lutil /data2/eoubrayrie/soft/openssl/lib/libssl.a /data2/eoubrayrie/soft/openssl/lib/libcrypto.a -ldl   /data2/eoubrayrie/soft/openssl/lib/libssl.a /data2/eoubrayrie/soft/openssl/lib/libcrypto.a -ldl   -lm  
libpython3.4m.a(config.o):(.data+0x158): undefined reference to `PyInit__hashopenssl'
collect2: ld returned 1 exit status

Editar 6:

No pude encontrar de todos modos para modificar cómo se genera _hashlib.so, ya que hay demasiada magia de Makefile involucrada (no aparece en ningún lado, ni '-lssl', sin embargo, ambos mágicamente terminan en la misma línea juntos

Pero puedo lograr que se vincule dinámicamente a mi propio openssl a través de un buen viejo -I / -L:

ldd build/lib.linux-x86_64-3.4/_hashlib.cpython-34m.so libssl.so.1.0.0 => /data2/soft/openssl/lib/libssl.so.1.0.0 (0x00007f5605799000) libcrypto.so.1.0.0 => /data2/soft/openssl/lib/libcrypto.so.1.0.0 (0x00007f56053bd000)

Ahora el único problema es, gdbinfo shared todavía me dice que otro se usa en el tiempo central ... pero ¿cómo?

From To Syms Read Shared Object Library 0x00007ffff5465930 0x00007ffff5466e98 Yes /data2/soft/python3/Python-3.4.0rc3/build/lib.linux-x86_64-3.4/_hashlib.cpython-34m.so 0x00007ffff5321220 0x00007ffff5351878 Yes /opt/python-2.6-64/lib/libssl.so.1.0.0 0x00007ffff50d3100 0x00007ffff519b118 Yes /opt/python-2.6-64/lib/libcrypto.so.1.0.0

env | grep -F 'python-2.6-64' -> no muestra nada!grep -RF 'python-2.6-64' /etc/ld.so.* -> idemgcc -print-search-dirs | sed 's/:/\n/g' | grep python -> idemfind . -name '*.so*' | xargs ldd | grep ssl -> solo me da los buenosLas dependencias de nivel 1 tampoco requieren ninguna versión SSL incorrecta. Esto fue verificado con:

find . -name '*.so*' | xargs ldd | awk '/\t+[[:alnum:].]+ => [[:alnum:]./]+ \(/ {print $3}' | sort | uniq | xargs ldd | grep ssl

strace ./python ./Tools/scripts/run_tests.py 2>&1 | grep python-2.6-64 -> no muestra nada

Entonces, ¿cómold elige esta biblioteca incorrecta si no puede saberlo? No está en ninguna ubicación estándar (si estuviera en / lib podría entender ...)

Solución:

Encontró cómo vincular estáticamente _hashlib gracias aeste error de OpenOffice: aunque el-Wl,--exclude-libs=ALL" La opción tampoco funcionó, me señaló las líneas correctas en setup.py.

TL; DR Aquí está elparche para setup.py Apliqué.

Y finalmente ... ¡funciona!

@noloader Estoy aceptando su respuesta más completa ya que su ayuda fue invaluable, aunque la respuesta "exacta" para cualquiera que encuentre este problema es compilar con el parche anterior.