使用自定义openssl版本编译python时的核心转储

当使用本地openssl-1.0.1f共享安装编译python-3.0rc3时, make 打印没有错误,但我在makeinstall或maketest上得到以下核心转储:

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 ?? ()

以下是使用的命令的完整列表

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

笔记:

操作系统为SUSE Linux Enterprise Server 11(x86_64)
将python指向位于
openssl是用 ./config shared --openssldir=/data2/soft/openssl
开放ssl make test 印刷品 所有测试均成功。
如果没有自定义的openssl*FLAGS,make安装将成功,我将获得以下make测试结果: 71 tests OK. tests failed: test_cmd_line test_gdb test_smtpnet test_ssl

我怎样才能解决这个问题,或者至少调查一下到底发生了什么?

编辑1-5:

正确生成了共享库:

> 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

所以我在安装程序中更改了此设置:

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

我相应地改回了LDFLAGS/CFLAGS。但当我运行make clean&&make,因为_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

我想这是导致核心的原因,因为它们仍然在那里。。。我尝试将类似的内容添加到安装文件中,但此文件没有注释项,创建它会导致另一个更神秘的失败:

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

编辑6:

无论如何,我都无法修改_hashlib.so的生成方式,因为Makefile魔法太多了(它不会出现在任何地方,'-lssl'也不会神奇地同时出现在同一行
但我可以通过旧的-I/-L将其动态链接到我自己的openssl:

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)
现在唯一的问题是,gdb info shared 告诉我还有一个是在核心时间使用的。。。但如何?

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' ->什么都没有!
- grep -RF 'python-2.6-64' /etc/ld.so.* ->同上
- gcc -print-search-dirs | sed 's/:/\n/g' | grep python ->同上
- find . -name '*.so*' | xargs ldd | grep ssl ->只给我好的
- 级别1依赖项也不需要任何错误的ssl版本。已通过以下方式进行检查:
  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 ->没有显示任何内容

那么 ld 如果他不知道,就选错了图书馆??它不在任何标准位置(如果它在/lib中,我可以理解…)

解决方案:

了解如何静态链接_hashlib this OpenOffice bug :尽管 -Wl,--exclude-libs=ALL" 选项也不起作用,它指向setup.py中正确的行。

TL;DR这是 patch to setup.py 我申请了。

最后。。。它起作用了!

@noloader我接受你最完整的答案,因为你的帮助是无价的,尽管对于任何遇到这个问题的人来说,“确切”的答案是使用上面的补丁进行编译。