2014-05-08 13 views
19

Ho la mia installazione OpenSSL in una posizione non standard (/my/path per questo esempio) e voglio che Python 3.4 lo costruisca contro quando lo compilo contro il sorgente. Quello che ho provato è questo (directory abbreviato)Come si compila Python 3.4 con OpenSSL personalizzato?

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

Ho provato anche con C_INCLUDE_PATH e percorsi di due punti separati.

Poi, corro make e ottenere questo:

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 

che sta cercando SSL_get0_next_proto_negotiated, ma che è certamente definita:

$ 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, 

io non sono sicuro di quello che sto facendo male, qualche idea?

+1

Avete i file '/ mio/percorso/lib/libssl.so' e/o'/mio/percorso/lib/libcrypto.so'? – rodrigo

+1

Dai un'occhiata a http://hg.python.org/cpython/file/9e55089aa505/setup.py per la logica che trova l'include ... – schlenk

+0

Grazie per quel link, lo verificherò –

risposta

28

Sono riuscito a capirlo dopo un sacco di strappare i capelli. E 'stato un gruppo di variabili d'ambiente ... Penso che avrei potuto fare un po' eccessivo, ma questo in fondo funzionato:

# 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

Probabilmente vorrai '-Wl, -rpath =/my/path/openssl/lib' nel tuo' LDFLAGS' in modo che la finestra apri personalizzata lib dir viene cotto nell'eseguibile risultante. Cioè quindi non è necessario impostare 'LD_LIBRARY_PATH' quando si esegue il tuo python. Non testato (mi dispiace). –

+0

Grazie, questo almeno ha avuto come risultato una build con le estensioni di openssl (che diverse altre ricette non sarebbero state ottenute). python 2.7.10, openssl 1.0.1 in ambiente openbuildservice. –

+0

Tuttavia, è una divulgazione completa: ho tutte le librerie che usiamo nello stesso progetto openbuildserver, così posso ricostruirle in batch in qualsiasi momento, altrimenti non varrebbe la pena di preoccuparsi di tutto questo. –

3

Ecco come ho risolto in 3.4. È applicabile per 2.7 e 3.4. L'importante è --with-ssl argomento config nella ./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

configure: ATTENZIONE: opzioni non riconosciute: --with-ssl – tsh

+0

Did il./ configura il passaggio con questo avviso? Il Python compilato ha abilitato ssl? A me sembra che configure non riconosca il parametro, ma viene comunque trasmesso e viene quindi ottimizzato da make. Ho approfondito questo argomento nel tempo secondo queste fonti: https://bugs.python.org/issue21541 e http://stackoverflow.com/questions/22409092/coredump-when-compiling-python-with-a-custom -openssl-version – dex

+0

Inoltre, se quanto sopra non funziona, allora potrebbe essere (anche se non ricordo con certezza) che ho integrato la patch dal ticket sopra http://bugs.python.org/file35304/issue21541-patch .diff Fammi sapere se funziona per te, per favore! – dex

7

Grazie @ScottFrazer per la sua risposta. Mi ha salvato un sacco di problemi.

Ecco uno script che ho usato in Ubuntu per compilare python con l'ultimo openssl 1.0.2g.

# 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 

Avviso, l'installazione è un altinstall il che significa che non di override il pitone di default su Ubuntu. Per verificare l'installazione è stata eseguita correttamente:

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

'CPPFLAGS' è per il preprocessore C. Probabilmente vuoi usare 'CFLAGS'. È compito del subacqueo del compilatore passare "CFLAGS" rilevanti al preprocessore. Il preprocessore non supera i flag rilevanti fino al driver del compilatore. – jww