2014-05-08 8 views
19

Ich habe meine eigene OpenSSL-Installation an einem nicht standardmäßigen Speicherort (/my/path für dieses Beispiel) und ich möchte Python 3.4 gegen das erstellen, wenn ich es gegen Quelle kompiliere. Was ich versucht ist diese (Verzeichnisse abgekürzt)Wie kompiliere ich Python 3.4 mit benutzerdefinierten OpenSSL?

CPPFLAGS="-I/my/path/include -I/my/path/include/openssl" ./configure --prefix=/my/path/ 

ich auch mit C_INCLUDE_PATH und Doppelpunkt getrennt Wege versucht.

Dann laufe ich make und bekommen dies:

building '_ssl' extension 
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/my/path/include -I/my/path/include/openssl -I/usr/local/include -I/my/path/Python-3.4.0/Include -I/my/path/Python-3.4.0 -c /my/path/Python-3.4.0/Modules/_ssl.c -o build/temp.linux-x86_64-3.4/my/path/Python-3.4.0/Modules/_ssl.o 
gcc -pthread -shared build/temp.linux-x86_64-3.4/my/path/Python-3.4.0/Modules/_ssl.o -L/my/path/lib -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-3.4/_ssl.cpython-34m.so 
*** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-x86_64-3.4/_ssl.cpython-34m.so: undefined symbol: SSL_get0_next_proto_negotiated 

Es ist für SSL_get0_next_proto_negotiated suchen, aber das ist mit Sicherheit definiert:

$ grep SSL_get0_next_proto_negotiated /my/path/include/openssl/* 
/my/path/include/openssl/ssl.h:void SSL_get0_next_proto_negotiated(const SSL *s, 

Ich bin mir nicht sicher, was ich falsch mache, irgendwelche Ideen?

+1

Haben Sie die Dateien '/ my/path/lib/libssl.so' und/oder'/my/path/lib/libcrypto.so'? – rodrigo

+1

Werfen Sie einen Blick auf http://hg.python.org/cpython/file/9e55089aa505/setup.py für die Logik, die die Includes findet ... – schlenk

+0

Danke für diesen Link, ich werde es überprüfen –

Antwort

28

Ich schaffte es nach viel Haarziehen herauszufinden. Es war eine Reihe von Umgebungsvariablen ... Ich glaube, ich könnte ein wenig übertrieben getan haben, aber im Grunde ist:

# OpenSSL 1.0.1g 
./config shared --prefix=/my/path --openssldir=/my/path/openssl 
make 
make install 

# Python 3.4 
export LDFLAGS="-L/my/path/lib/ -L/my/path/lib64/" 
export LD_LIBRARY_PATH="/my/path/lib/:/my/path/lib64/" 
export CPPFLAGS="-I/my/path/include -I/my/path/include/openssl" 
./configure --prefix=/my/path/ 
make 
make install 
+2

Sie wollen wahrscheinlich '-Wl, -rpath =/mein/Pfad/openssl/lib' in Ihrem' LDFLAGS' so die benutzerdefinierte openssl lib dir wird in die resultierende ausführbare Datei eingebunden. I.e. Sie müssen also nicht LD_LIBRARY_PATH setzen, wenn Sie Ihren Python ausführen. Nicht getestet (Entschuldigung). –

+0

Danke, dieser hat zumindest zu einem Build mit openssl Erweiterungen geführt (was verschiedene andere Rezepte nicht erreichen würden). Python 2.7.10, OpenSSL 1.0.1 in der OpenBuildService-Umgebung. –

+0

Volle Enthüllung obwohl - ich habe alle libs, die wir im selben openbuildserver Projekt verwenden, also kann ich sie jederzeit im Stapel wieder aufbauen, sonst würde es sich nicht lohnen, sich mit all dem zu beschäftigen. –

3

Dies ist, wie ich es in 3.4 gelöst. Es gilt für 2.7 und 3.4. Das ist wichtig --with-ssl Config-Argument in dem configure:

wget https://www.python.org/ftp/python/3.4.3/Python-3.4.3.tgz 
tar -xf Python-3.4.3.tgz 
cd Python-3.4.3/ 
sudo yum install gcc 
./configure --with-ssl 
make && make install 
# If you like to live dangerously since this will overwrite default python executable 
make && make altinstall 
# Safer because you access your new Python using python3.4 
+5

konfigurieren: WARNUNG: nicht erkannte Optionen: --with-ssl – tsh

+0

Hat die./ config mit dieser Warnung? Hat das kompilierte Python ssl aktiviert? Für mich sieht es so aus, als ob configure den Parameter nicht erkennt, aber trotzdem weitergegeben wird und dann von make gehont wird. Ich habe in dieser Zeit nach diesen Quellen gegraben: https://bugs.python.org/issue21541 und http://stackoverflow.com/questions/22409092/coredump-when-compiling-python-with-a-custom -Openssl-Version – dex

+0

Darüber hinaus, wenn das obige nicht funktioniert, dann kann es sein (obwohl ich nicht mit Sicherheit daran erinnern), dass ich den Patch aus dem obigen Ticket http://bugs.python.org/file35304/issue21541-patch integriert .diff Lass es mich wissen, wenn es für dich funktioniert! – dex

7

Dank @ScottFrazer für seine Antwort. Er hat mir viele Probleme erspart.

Hier ist ein Skript, das ich in Ubuntu verwendet, um Python mit der neuesten openssl 1.0.2g zu kompilieren.

# new openssl install 
curl https://www.openssl.org/source/openssl-1.0.2g.tar.gz | tar xz && cd openssl-1.0.2g && ./config shared --prefix=/usr/local/ && make && make install 

# Python install script 
export LDFLAGS="-L/usr/local/lib/" 
export LD_LIBRARY_PATH="/usr/local/lib/" 
export CPPFLAGS="-I/usr/local/include -I/usr/local/include/openssl" 
apt-get update 
apt-get install build-essential checkinstall -y 
apt-get install libreadline-gplv2-dev libncursesw5-dev libssl-dev libsqlite3-dev tk-dev libgdbm-dev libc6-dev libbz2-dev -y 
cd /home/web/ 
wget https://www.python.org/ftp/python/2.7.11/Python-2.7.11.tgz | tar xzf Python-2.7.11.tgz && cd Python-2.7.11 
./configure --prefix=/usr/local/ 
make altinstall 

Hinweis, installieren Sie das eine altinstall was bedeutet, es wird nicht Überschreibung der Standard-Python auf Ubuntu. Um zu überprüfen, die Installation erfolgreich war:

/usr/local/bin/python2.7 
>>> import ssl 
>>> ssl.OPENSSL_VERSION 
'OpenSSL 1.0.2g 1 Mar 2016' 
+0

'CPPFLAGS' ist für den C-Präprozessor. Sie möchten wahrscheinlich 'CFLAGS' verwenden. Es ist die Aufgabe des Compiler-Tauchers, relevante 'CFLAGS' an den Präprozessor weiterzuleiten. Der Präprozessor übergibt keine relevanten Flags an den Compilertreiber. – jww