Сборка gdb 10.1 из исходников с помощью пользовательского python

Я пытаюсь собрать последнюю версию gdb 10.1 из исходного кода.

[Причина, по которой я хочу это сделать, заключается в том, что я пытаюсь отладить программу, которая ссылается на пользовательскую сборку Python 2.7.18, а моя система gdb была связана со сборкой Python 2.7.5 в моем каталоге /lib64 и не работает с более новой версией].

Прочитав файл README, я настроил с помощью:

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

... а затем запустить

make all install

...по инструкции. Однако каждая попытка сборки завершается сбоем в виде множества сообщений об ошибках вида:

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'

Изучив выходные данные шага configure и сам Makefile, я не могу найти никакой ссылки на установку Python, которую я указал во время настройки (и которую я также поместил в заголовок моего LD_LIBRARY_PATH, чтобы гарантировать, что компилятор и компоновщик может найти его при сборке).

Что мне здесь не хватает?


linux makefile gdb gdb-python
person Eos Pengwern    schedule 27.10.2020    source источник
comment
Если вы делаете grep PYTHON_CPPFLAGS /path/to/your/build/directory/gdb/config.log (или config.status), относятся ли параметры -I к каталогу, содержащему Python.h?   -  person Mark Plotnick    schedule 27.10.2020
comment
Нет, я вообще не могу найти PYTHON_CPPFLAGS, в том числе и в make-файле. Как в config.log, так и в config.status есть несколько мест, где записана моя строка --with-python, но нигде не видно, что в свете этого было предпринято какое-либо действие.   -  person Eos Pengwern    schedule 27.10.2020
comment
Хорошо, поищите в config.log в каталоге build/gdb строки, начинающиеся с checking whether to use python и checking compiler flags for python code, и посмотрите, успешно ли выполнены тестовые программы.   -  person Mark Plotnick    schedule 27.10.2020
comment
Хм... Все в файле gdb/config.log выглядит так, как я и ожидал. Тесты Python запущены, они возвращаются как результат: да, и PYTHON_CPPFLAGS определен правильно в файле gdb/config.log и файле gdb/config.status (в моем предыдущем ответе я сделал ошибку, заглянув только в основной каталог сборки, а не в подкаталоге gdb). Затем правильный путь к Python.h включается в определение INTERNAL_CPPFLAGS в gdb/Makefile. Но сборка по-прежнему не работает, как описано изначально.   -  person Eos Pengwern    schedule 28.10.2020
comment
Я также вижу, что в gdb/config.h макрос WITH_PYTHON_LIBDIR правильно установлен в каталог, содержащий мой файл libpython2.7.so.1.0.   -  person Eos Pengwern    schedule 28.10.2020
comment
Что особенного в моей сборке Python 2.7.18, так это то, что она была сделана с использованием переключателя компилятора -fno-semantic-interposition и переключателя компоновщика --default-symver. Может ли это иметь какое-то влияние? Я не могу сказать, относится ли сообщение об ошибке неопределенной ссылки к этапу компиляции или к этапу компоновщика, хотя тот факт, что оно связано с файлом .h, делает первое более вероятным.   -  person Eos Pengwern    schedule 28.10.2020
comment
См. примечание ниже: Наконец, просто для удовольствия, я сделал то же самое снова, установив --with-python для системной установки Python в /usr/bin/python. Это сработало просто отлично! Таким образом, проблема явно связана с моей собственной сборкой Python (хотя она отлично работает для всего остального, что я пытался с ней сделать) или с каким-то очень неясным аспектом пути к ней.   -  person Eos Pengwern    schedule 28.10.2020
comment
Можете ли вы привести аргументы, которые вы дали .../configure как для gdb, так и для python?   -  person Mark Plotnick    schedule 28.10.2020
comment
Давайте продолжим обсуждение в чате.   -  person Eos Pengwern    schedule 28.10.2020

Ответы (1)


arrow_upward
0
arrow_downward

Недавно делал что-то подобное, и тоже бился, хотя и по другим задачам.

Я подозреваю, что ваша проблема со сборкой может быть связана с использованием вами LD_LIBRARY_PATH или другими вещами, исходящими из вашей среды (PATH, CFLAGS, LDFLAGS и т. д.). Вам не нужно устанавливать их во время сборки.

Вот схема того, что я сделал:

(1) Для сборки gdb я использовал такой подход:

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

Набор PATH и сброс LD_LIBRARY_PATH предназначены для очистки среды. Это гарантирует, что сборка может использовать только --with-python для поиска python (который сам находится в bin/python под префиксом python). (CFLAGS и LDFLAGS также не были установлены, как и какие-либо переменные PYTHON.)

Я сохранил вывод стадии make. Если вы посмотрите туда, то увидите, что опция with-python выбрана.

Это все построено нормально.

(2) Чтобы вызвать отладчик (и использовать мой python в /opt), мне потребовался дополнительный шаг: установить LD_LIBRARY_PATH, чтобы использовался мой python libpython:

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.

Было бы неплохо найти способ избежать необходимости устанавливать LD_LIBRARY_PATH; это, возможно, потребует статической компоновки libpython или введения некоторых флагов сборки, например, для использования rpath.

person Darren Smith    schedule 27.10.2020
comment
Давайте попробуем; вся эта проблема обнаружилась, когда я установил LD_LIBRARY_PATH, поскольку до этого мое собственное приложение не могло найти необходимую сборку Python. Как только я установил его, я обнаружил, что мое приложение работает, но отладчик больше не работает! - person Eos Pengwern; 27.10.2020
comment
ОК, я попытался построить снова с минимальным PATH, пустым LD_LIBRARY_PATH и убедился, что не установлены переменные PYTHON (т.е. PYTHONPATH/PYTHONHOME) или переменные FLAGS. Я также попробовал это на совершенно другой машине с той же сборкой Python. Тот же результат. Наконец, просто для удовольствия, я сделал то же самое снова, установив --with-python для системной установки Python в /usr/bin/python. Это сработало просто отлично! Таким образом, проблема явно связана с моей собственной сборкой Python (хотя она отлично работает для всего остального, что я пытался с ней сделать) или с каким-то очень неясным аспектом пути к ней. - person Eos Pengwern; 28.10.2020
comment
Когда вы создавали свой собственный Python, добавляли ли вы --with-pydebug для создания отладочной сборки? Это может привести к появлению дополнительных отладочных символов (таких как _Py_RefTotal), что может быть еще одной причиной. - person Darren Smith; 28.10.2020
comment
Интересно, что вы должны сказать: все, что сообщалось выше о моей пользовательской сборке, касалось ее версии, скомпилированной с помощью --with-pydebug. У меня есть другая сборка, которая была скомпилирована без него, поэтому я попытался использовать это... и получил несколько похожих, но разных ошибок, на этот раз касающихся неопределенных ссылок на PyUnicodeUCS2_Decode и другие функции в этом семействе. Теперь я также проверил, что мой пользовательский Python был скомпилирован с использованием UCS2 (print sys.maxunicode возвращает 65535), поэтому я не чувствую себя намного мудрее. - person Eos Pengwern; 28.10.2020
comment
Что ж, наличие этих отсутствующих символов, таких как _Py_RefTotal, связано с тем, что вы создали Python с --with-pydebug. Я думаю, вы должны попытаться сделать простую и чистую сборку Python, то есть свести к минимуму количество флагов и посмотреть, решит ли это проблему. В настоящее время у вас есть несколько движущихся частей и т. д. - person Darren Smith; 28.10.2020
comment
Что бы это ни стоило, я решил свою основную проблему по-другому. Я временно добавил путь к моей пользовательской сборке Python в RPATH моего приложения (используя свойство CMake BUILD_RPATH), чтобы мое собственное приложение могло получать пользовательский Python в то же время, когда gdb использует стандартный Python. - person Eos Pengwern; 29.10.2020