2009-10-10 15 views
6

Sommario: la creazione di Python 3.1 su RHEL 5.3 64 bit con --enable-shared non riesce a compilare tutte le estensioni. Costruire "normale" funziona bene senza problemi.Python 3.1.1 con --enable-shared: non creerà alcuna estensione

Si prega di notare che questa domanda potrebbe sembrare confusa tra la programmazione e l'amministrazione del sistema. Tuttavia, io credo che, poiché deve gestire direttamente il supporto linguistico, e ciò ha molto a che fare con il supporto del processo di programmazione, che vorrei poi pubblicare qui. Inoltre: https://serverfault.com/questions/73196/python-3-1-1-with-enable-shared-will-not-build-any-extensions. Grazie!

Problema:

costruzione Python 3.1 su RHEL 5.3 a 64 bit con --enable-shared non riesce a compilare tutte le estensioni. Costruire "normale" funziona bene senza problemi.

Posso costruire python 3.1 bene, ma una volta creato come libreria condivisa, emette molti avvisi (vedi sotto), e si rifiuta di costruire uno dei moduli basati su c. Nonostante questo errore, posso ancora creare mod_wsgi 3.0c5 contro di esso ed eseguirlo sotto apache. Inutile dire che la funzionalità di Python è notevolmente ridotta ...

Interessante notare che Python 3.2a0 (da svn) compila bene con --enable-shared, e mod_wsgi compila bene contro di esso. Ma quando si inizia apache, ottengo:

Cannot load /etc/httpd/modules/mod_wsgi.so into server: /etc/httpd/modules/mod_wsgi.so: undefined symbol: PyCObject_FromVoidPtr

Il progetto che questo è per è un progetto a lungo termine, quindi sto bene con software di qualità alpha, se necessario. Ecco alcuni ulteriori dettagli sul problema.

Host:

  • Dell PowerEdge
  • Intel Xenon
  • RHEL 5.3 a 64 bit
  • Niente "speciale"

Corporatura:

  • Python 3.1.1 fonte di distribuzione
  • funziona bene con ./configure
  • Non funziona bene con ./configure --enable-shared

(export CFLAGS="-fPIC" è stato fatto)

make uscita


gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -c ./Modules/_weakref.c -o Modules/_weakref.o


building 'bz2' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude -I/home/build/RPMBUILD/BUILD/Python-3.1.1 -c /home/build/RPMBUILD/BUILD/Python-3.1.1/Modules/bz2module.c -o build/temp.linux-x86_64-3.1/home/build/RPMBUILD/BUILD/Python-3.1.1/Modules/bz2module.o gcc -pthread -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-x86_64-3.1/home/build/RPMBUILD/BUILD/Python-3.1.1/Modules/bz2module.o -L/usr/local/lib -L. -lbz2 -lpython3.1 -o build/lib.linux-x86_64-3.1/bz2.so /usr/bin/ld: /usr/local/lib/libpython3.1.a(abstract.o): relocation R_X86_64_32 against 'a local symbol' can not be used when making a shared object; recompile with -fPIC


Failed to build these modules: 
_bisect   _codecs_cn   _codecs_hk 
_codecs_iso2022 _codecs_jp   _codecs_kr 
_codecs_tw   _collections  _csv 
_ctypes   _ctypes_test  _curses 
_curses_panel  _dbm    _elementtree 
_gdbm    _hashlib   _heapq 
_json    _lsprof   _multibytecodec 
_multiprocessing _pickle   _random 
_socket   _sqlite3   _ssl 
_struct   _testcapi   array 
atexit    audioop   binascii 
bz2    cmath    crypt 
datetime   fcntl    grp 
itertools   math    mmap 
nis    operator   ossaudiodev 
parser    pyexpat   readline 
resource   select    spwd 
syslog    termios   time 
unicodedata  zlib 

risposta

5

qualcosa che non va con il vostro ambiente di sviluppo. Sta prendendo un libpython3.1.a da /usr/local/lib; questo confonde i messaggi di errore. Prova a collegarsi con quella libreria, che fallisce - tuttavia, non dovrebbe averlo provato in primo luogo, dal momento che avrebbe dovuto usare il libpython che aveva appena creato. Mi raccomando di prendere l'installazione di Python 3.1 in /usr/local di mezzo.

Non viene mostrato nell'output se è stato creato un libpython3.1.so.1.0 nell'albero di build; sarebbe importante scoprire se esiste, come è stato collegato e quali simboli ha esportato.

+0

Ciao Martin, vorrei commentare che questo problema al 100% ha risolto il problema. Grazie! Hai idea del motivo per cui cercherebbe in/usr/local invece di/home/build/RPMBUILD/BUILD/...? – gahooa

+1

Rileggendo la riga del linker, diventa chiaro: '-L/usr/local/lib' è prima di' -L. –

0

/usr/local/lib è stato aggiunto alla libreria percorso di inclusione in fase di compilazione:

-L/usr/local/lib -L.

È comune per il tempo di compilazione cercare in più percorsi "comuni" per le librerie (/ usr/lib,/usr/local/lib, ./, ecc.) Ma anche, probabilmente, è possibile selezionare/usr/local/lib dalla variabile di ambiente LD_LIBRARY_PATH e attaccandola al comando di compilazione.

+0

Interessante ... Come indicheresti di guardare in "." PRIMA, prima altrove? – gahooa

+0

La variabile LD_LIBRARY_PATH non dovrebbe essere usata in questo modo, quindi se sta usando le directory da LD_LIBRARY_PATH per aggiungere ai flag del compilatore, è discutibilmente rotto. –

Problemi correlati