Membangun gdb 10.1 dari sumber dengan python khusus

Saya mencoba membuat gdb 10.1 terbaru dari sumber.

[Alasan saya ingin melakukannya adalah karena saya mencoba men-debug program yang tertaut ke build kustom Python 2.7.18, dan gdb sistem saya ditautkan ke build Python 2.7.5 di direktori /lib64 saya dan tidak berfungsi dengan versi yang lebih baru].

Setelah membaca file README, saya telah mengkonfigurasi menggunakan:

../gdb-10.1/configure --with-python=<path to my 2.7.18 installation> --prefix=<path to where I want the new gdb to go>

...dan kemudian lari

make all install

... sesuai instruksi. Namun, setiap upaya untuk membangun kemudian gagal dan menghasilkan banyak pesan kesalahan dalam bentuk:

python/py-arch.o: In function `gdbarch_to_arch_object(gdbarch*)':
.../build/gdb/../../../gdb-10.1/gdb/python/py-arch.c:86: undefined reference to `_Py_RefTotal'
python/py-arch.o: In function `gdbpy_ref_policy<_object>::decref(_object*)':
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_NegativeRefcount'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_Dealloc'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_NegativeRefcount'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_Dealloc'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_RefTotal'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_Dealloc'
.../build/gdb/../../../gdb-10.1/gdb/python/py-ref.h:36: undefined reference to `_Py_NegativeRefcount'

Saat memeriksa output dari langkah konfigurasi, dan Makefile itu sendiri, saya tidak dapat menemukan referensi sama sekali untuk instalasi Python yang saya tentukan pada waktu konfigurasi (dan yang juga saya tempatkan di kepala LD_LIBRARY_PATH saya untuk memastikan bahwa kompiler dan linker dapat menemukannya saat membangun).

Apa yang kulewatkan di sini?


linux makefile gdb gdb-python
person Eos Pengwern    schedule 27.10.2020    source sumber
comment
Jika Anda melakukan grep PYTHON_CPPFLAGS /path/to/your/build/directory/gdb/config.log (atau config.status) , apakah opsi -I merujuk ke direktori yang berisi Python.h ?   -  person Mark Plotnick    schedule 27.10.2020
comment
Tidak, saya tidak dapat menemukan PYTHON_CPPFLAGS sama sekali, tidak juga di makefile. Ada beberapa tempat di config.log dan config.status di mana string --with-python saya direkam, tetapi tidak terlihat ada tindakan yang diambil sehubungan dengan hal tersebut.   -  person Eos Pengwern    schedule 27.10.2020
comment
Oke, lihat di config.log di direktori build/gdb untuk baris yang dimulai dengan checking whether to use python dan checking compiler flags for python code dan lihat apakah program pengujian berhasil.   -  person Mark Plotnick    schedule 27.10.2020
comment
Hm.. Segala sesuatu di file gdb/config.log tampak seperti yang saya harapkan. Tes Python dijalankan, hasilnya kembali: ya, dan PYTHON_CPPFLAGS didefinisikan dengan benar dalam file gdb/config.log dan file gdb/config.status (dalam balasan saya sebelumnya, saya membuat kesalahan dengan hanya mencari di direktori build utama, bukan di subdirektori gdb). Jalur yang benar ke Python.h kemudian dimasukkan dalam definisi INTERNAL_CPPFLAGS di gdb/Makefile. Namun pembangunannya masih gagal seperti yang dijelaskan semula.   -  person Eos Pengwern    schedule 28.10.2020
comment
Saya juga dapat melihat bahwa, dalam gdb/config.h, makro WITH_PYTHON_LIBDIR disetel dengan benar ke direktori yang berisi file libpython2.7.so.1.0 saya.   -  person Eos Pengwern    schedule 28.10.2020
comment
Hal yang khusus tentang build Python 2.7.18 saya adalah bahwa ia dibuat menggunakan sakelar kompiler -fno-semantic-interposition dan sakelar linker --default-symver. Mungkinkah ini ada pengaruhnya? Saya tidak tahu apakah pesan kesalahan referensi yang tidak ditentukan mengacu pada tahap kompilasi atau tahap linker, meskipun fakta bahwa pesan tersebut dikaitkan dengan file .h membuat yang pertama lebih mungkin terjadi.   -  person Eos Pengwern    schedule 28.10.2020
comment
Lihat catatan di bawah: Akhirnya, hanya untuk iseng, saya melakukan hal yang sama lagi, mengatur --with-python ke instalasi sistem Python di /usr/bin/python. Itu berhasil dengan baik! Jadi jelas masalahnya ada pada build Python saya sendiri (meskipun berfungsi dengan baik untuk semua hal lain yang telah saya coba lakukan dengannya), atau beberapa aspek yang sangat tidak jelas dari jalur ke sana.   -  person Eos Pengwern    schedule 28.10.2020
comment
Bisakah Anda memberi kami argumen yang Anda berikan kepada .../configure untuk gdb dan python?   -  person Mark Plotnick    schedule 28.10.2020
comment
Mari kita melanjutkan diskusi ini dalam chat.   -  person Eos Pengwern    schedule 28.10.2020

Jawaban (1)


arrow_upward
0
arrow_downward

Saya melakukan hal serupa baru-baru ini, dan juga berjuang, meskipun untuk masalah yang berbeda.

Saya menduga masalah build Anda mungkin terkait dengan penggunaan LD_LIBRARY_PATH, atau hal lain yang berasal dari lingkungan Anda (PATH, CFLAGS, LDFLAGS, dll). Anda tidak perlu mengaturnya selama pembuatan.

Berikut garis besar dari apa yang saya lakukan:

(1) Untuk pembuatan gdb, saya menggunakan pendekatan seperti ini:

export PATH=/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin
unset LD_LIBRARY_PATH 
../gdb-10.1/configure --prefix=/opt/gdb-10.1  --with-python=/opt/conda-py2.7.18 
make         &> make.log
make install &> make-install.log

Kumpulan PATH dan tidak disetelnya LD_LIBRARY_PATH dimaksudkan untuk membersihkan lingkungan. Hal ini memastikan build hanya dapat menggunakan --with-python untuk menemukan lokasi python (yang berada di bin/python, di bawah awalan python). (CFLAGS & LDFLAGS juga tidak disetel, begitu pula variabel PYTHON apa pun.)

Saya menyimpan output dari tahap make. Jika Anda melihat ke sana, Anda akan melihat opsi with-python diambil.

Ini semua dibangun dengan baik.

(2) Untuk memanggil debugger (dan menggunakan python saya di bawah /opt), saya memerlukan langkah tambahan: untuk mengatur LD_LIBRARY_PATH sehingga libpython python saya digunakan:

export LD_LIBRARY_PATH=/opt/conda-py2.7.18/lib
/opt/gdb-10.1/bin/gdb
(gdb) python import sys; print(sys.version)
2.7.18 | Anaconda, Inc.

Akan menyenangkan untuk menemukan cara untuk menghindari kebutuhan untuk mengatur LD_LIBRARY_PATH; ini mungkin memerlukan penautan libpython secara statis, atau pengenalan beberapa flag build, misalnya, untuk menggunakan rpath.

person Darren Smith    schedule 27.10.2020
comment
Ayo kita mulai; seluruh masalah ini terungkap ketika saya mengatur LD_LIBRARY_PATH, karena sebelum saya melakukannya, aplikasi saya sendiri tidak dapat menemukan build Python yang diperlukan. Saat saya mengaturnya, saya menemukan aplikasi saya berfungsi tetapi debugger tidak lagi berfungsi! - person Eos Pengwern; 27.10.2020
comment
Oke, saya mencoba membangun lagi dengan PATH minimal, LD_LIBRARY_PATH kosong dan memastikan tidak ada variabel PYTHON yaitu variabel PYTHONPATH/PYTHONHOME) atau FLAGS yang disetel. Saya juga mencobanya pada mesin yang sama sekali berbeda, dengan build Python yang sama. Hasil yang sama. Akhirnya, hanya untuk iseng, saya melakukan hal yang sama lagi, mengatur --with-python ke instalasi sistem Python di /usr/bin/python. Itu berhasil dengan baik! Jadi jelas masalahnya ada pada build Python saya sendiri (meskipun berfungsi dengan baik untuk semua hal lain yang telah saya coba lakukan dengannya), atau beberapa aspek yang sangat tidak jelas dari jalur ke sana. - person Eos Pengwern; 28.10.2020
comment
Saat Anda membuat python khusus, apakah Anda menambahkan --with-pydebug untuk membuat build debug? Hal ini dapat menimbulkan simbol debug tambahan (seperti _Py_RefTotal), jadi mungkin ada penyebab lainnya. - person Darren Smith; 28.10.2020
comment
Menariknya Anda harus mengatakan bahwa: semua yang dilaporkan di atas tentang bangunan khusus saya berkaitan dengan versi yang dikompilasi dengan --with-pydebug. Saya memiliki build lain yang dikompilasi tanpanya, jadi saya mencoba menggunakan ini... dan mendapatkan beberapa kesalahan serupa tetapi berbeda, kali ini mengenai referensi yang tidak terdefinisi ke PyUnicodeUCS2_Decode dan fungsi lain dalam keluarga itu. Sekarang, saya juga telah memeriksa bahwa Python kustom saya dikompilasi menggunakan UCS2 (print sys.maxunicode mengembalikan 65535), jadi saya merasa tidak lebih bijaksana. - person Eos Pengwern; 28.10.2020
comment
Kehadiran simbol-simbol yang hilang seperti _Py_RefTotal itu karena Anda membuat python dengan --with-pydebug. Saya pikir Anda harus mencoba membuat versi python yang sederhana & bersih, yaitu meminimalkan jumlah tanda, dan melihat apakah itu menyelesaikan masalah. Saat ini Anda memiliki beberapa bagian yang bergerak, dll. - person Darren Smith; 28.10.2020
comment
Apa gunanya, saya telah memecahkan masalah mendasar saya dengan cara yang berbeda. Saya untuk sementara menambahkan path ke build Python kustom saya ke RPATH aplikasi saya (menggunakan properti BUILD_RPATH CMake) sehingga saya dapat membuat aplikasi saya sendiri mengambil Python kustom pada saat yang sama ketika gdb menggunakan Python standar. - person Eos Pengwern; 29.10.2020