Python 3.1.1 z --enable-shared: nie będzie budować żadnych rozszerzeń

Question

Podsumowanie: Building Python 3.1 na RHEL 5.3 64-bitowy z --enable-shared nie kompiluje wszystkich rozszerzeń. Budynek "normalny" działa dobrze bez żadnych problemów.

Uwaga: wydaje się, że to pytanie zaciera granicę między programowaniem a administrowaniem systemem. Uważam jednak, że ponieważ musi się bezpośrednio zajmować uzyskaniem wsparcia językowego i ma to wiele wspólnego ze wsparciem procesu programowania, zamieściłem go tutaj. Również pod adresem: https://serverfault.com/questions/73196/python-3-1-1-with-enable-shared-will-not-build-any-extensions. Dziękuję Ci!

Problem:

budynku Python 3.1 na RHEL 5.3 64 bit z --enable-shared nie skompilować wszystkie rozszerzenia. Budynek "normalny" działa dobrze bez żadnych problemów.

Mogę zbudować python 3.1, ale po zbudowaniu jako biblioteka współdzielona emituje wiele ostrzeżeń (patrz poniżej) i odmawia zbudowania jednego z modułów opartych na c. Pomimo tego niepowodzenia nadal mogę zbudować przeciwko niemu mod_wsgi 3.0c5 i uruchomić go pod apache. Nie trzeba dodawać, że funkcjonalność Pythona jest znacznie mniejsza ...

Interesujące jest to, że Python 3.2a0 (z svn) kompiluje się dobrze z --enable-shared, a mod_wsgi kompiluje przeciwko niemu dobrze. Ale gdy zaczyna apache, otrzymuję:

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

projektu, że jest za to projekt długoterminowy, więc jestem w porządku z oprogramowaniem jakości alfa w razie potrzeby. Oto kilka szczegółów dotyczących problemu.

Host:

• Dell PowerEdge
• Intel Xenon
• RHEL 5.3 64bit
• Nic "specjalne"

Budowa:

• Python 3.1.1 źródło dystrybucji
• współpracuje z ./configure
• Nie działa dobrze z ./configure --enable-shared

(export CFLAGS="-fPIC" zostało zrobione)

make wyjście

---

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 

Answer 1

Coś jest nie tak z twoim środowisku kompilacji. Odbiera libpython3.1.a od /usr/local/lib; to myli komunikaty o błędach. Próbuje połączyć się z tą biblioteką, która się nie udaje - jednak nie powinna była tego wypróbować, ponieważ powinna była użyć libpythona, który właśnie zbudowała. Zalecam zabranie instalacji Python 3.1 w jedną stronę.

Nie pokazujesz na wyjściu, czy plik libpython3.1.so.1.0 został utworzony w drzewie kompilacji; ważne jest, aby dowiedzieć się, czy istnieje, jak został połączony i jakie symbole wyeksportował.

Answer 2

/usr/local/lib został dodany do biblioteki obejmują drogę w czasie kompilacji

-l/usr/local/lib -l.

Typowe dla kompilacji jest szukanie wielu "powszechnych" ścieżek dla bibliotek (/ usr/lib,/usr/local/lib, ./, itp.), Ale także, prawdopodobnie podnosząc/usr/local/lib ze zmiennej środowiskowej LD_LIBRARY_PATH i przypisanie jej do polecenia budowania.