☰

Openssl 1.1.1을 사용하여 Python 2.7.16을 빌드할 수 있습니까?

tag-icon • tag-icon python openssl
Openssl 1.1.1을 사용하여 Python 2.7.16을 빌드할 수 있습니까?

나는 Python이 설치된 OpenSSL 버전을 사용하지 않고 대신 자체 SSL 모듈을 사용하고 업그레이드하기 위해 다시 빌드해야 한다고 가정하는 것이 옳다고 생각합니다.

이것은 Raspbian Jessie를 기반으로 한 작은 비 GUI 이미지인 Raspberry Pi에 있습니다. 나중에 시간이 허락되면 현재 배포판을 기반으로 전체 재구축을 계획하고 있습니다. 지금은 중요한 패키지만 수동으로 업그레이드하고 싶습니다.

git에서 OpenSSL 소스를 복제하고 1.1.1-stable 브랜치를 확인한 후 빌드했습니다. 그냥 기본값 configure, make및 make test.sudo make install

이제 이 버전을 사용하기 위해 Python을 다시 빌드하려고 합니다.

Python 3에서 작동하도록 만들었지만 Python 2에서는 실패합니다. 둘 다 오늘 www.python.org/downloads/source/에서 다운로드한 타르볼이며 추가 옵션이 있거나 없이 ./configure빌드 되었습니다.make

3.7.3의 결과: make가 성공하고 이 테스트도 성공합니다.

$ ./python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 1.1.1d-dev  xx XXX xxxx

이전(설치된) 버전의 Python은 Python3뿐만 아니라 Python용 OpenSSL 1.0.1t도 보고하므로 새 빌드에서는 새 버전을 사용합니다.

2.7.16의 결과: make는 부분적으로만 성공했지만 다음으로 끝납니다.

Failed to build these modules:
_hashlib           _ssl

그리고 같은 테스트가 진행됩니다

$ ./python -c "import ssl; print(ssl.OPENSSL_VERSION)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/src/python/Python-2.7.16/Lib/ssl.py", line 98, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: No module named _ssl

해당 모듈을 빌드할 때 출력하십시오.

building '_ssl' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include/arm-linux-gnueabihf -I/usr/local/include -I/usr/local/src/python/Python-2.7.16/Include -I/usr/local/src/python/Python-2.7.16 -c /usr/local/src/python/Python-2.7.16/Modules/_ssl.c -o build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_ssl.o
gcc -pthread -shared build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_ssl.o -L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-armv7l-2.7/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-armv7l-2.7/_ssl.so: undefined symbol: OPENSSL_sk_num
building '_hashlib' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include/arm-linux-gnueabihf -I/usr/local/include -I/usr/local/src/python/Python-2.7.16/Include -I/usr/local/src/python/Python-2.7.16 -c /usr/local/src/python/Python-2.7.16/Modules/_hashopenssl.c -o build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_hashopenssl.o
gcc -pthread -shared build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_hashopenssl.o -L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-armv7l-2.7/_hashlib.so
*** WARNING: renaming "_hashlib" since importing it failed: build/lib.linux-armv7l-2.7/_hashlib.so: undefined symbol: OPENSSL_init_crypto

답변1

질문에 대한 내 의견에서와 같이 대답은 '예'입니다.

[편집: 처음에는 내 CFLAGS인 줄 알았는데 아니었습니다.]

드디어 얻었습니다. _ssl 모듈의 빌드 명령에는 다음 스위치가 포함되어 있습니다. -L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib

두 위치 중 첫 번째 위치에는 여전히 libssl.so의 이전(1.0.0) 버전이 포함되어 있습니다. 올바른 버전은 두 번째 경로에 있었습니다.

재미있는 점은 3.7.3을 빌드할 때 2.7.16에 대해서만 아무런 차이가 없는 것 같다는 것입니다.

관련 정보