Как устранить эти ошибки установки для Python 3.11.9?
Я пытаюсь настроить и «установить» Python 3.11.9. Однако папка lib не создается, а папка bin пуста. Выполнено в Ubuntu 22:04 с установленной версией Python 3.10.12. Ниже приведены лишь некоторые из них.
Команды, отправленные из папки отладки:
../configure --prefix=/usr --with-ensurepip=install --enable-optimizations
make -j$(nproc) DESTDIR=/home/user/project/myapp.AppDir install
Ошибка 1: Образец. Их много, и все они в PyCharm имеют красный цвет.
/usr/bin/ld: Python/errors.o: in function `_PyErr_Fetch':
/home/user/project/src/Python-3.11.9/debug/../Python/errors.c:428: undefined reference to `__gcov_indirect_call'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:428: undefined reference to `__gcov_indirect_call_profiler_v4'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:428: undefined reference to `__gcov_time_profiler_counter'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:428: undefined reference to `__gcov_time_profiler_counter'
/usr/bin/ld: Python/errors.o: in function `PyErr_GivenExceptionMatches':
/home/user/project/src/Python-3.11.9/debug/../Python/errors.c:255: undefined reference to `__gcov_indirect_call'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:255: undefined reference to `__gcov_indirect_call_profiler_v4'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:255: undefined reference to `__gcov_time_profiler_counter'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:255: undefined reference to `__gcov_time_profiler_counter'
/usr/bin/ld: Python/errors.o: in function `PyErr_ExceptionMatches':
/home/user/project/src/Python-3.11.9/debug/../Python/errors.c:294: undefined reference to `__gcov_indirect_call'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:294: undefined reference to `__gcov_indirect_call_profiler_v4'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:294: undefined reference to `__gcov_time_profiler_counter'
/usr/bin/ld: /home/user/project/src/Python-3.11.9/debug/../Python/errors.c:294: undefined reference to `__gcov_time_profiler_counter'
Ошибка 2:
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make: *** [Makefile:1203: Programs/_freeze_module] Error 1
Ошибка 3: Это было последнее сообщение, появившееся перед завершением.
# This is an expensive target to build and it does not have proper
# makefile dependency information. So, we create a "stamp" file
# to record its completion and avoid re-running it.
Если вы хотите установить произвольные версии Python в произвольный дистрибутив, я бы предложил использовать внешний менеджер пакетов, который сделает это за вас. Лично я использую и рекомендую Nix (см. nixos.org), но есть еще много других — GNU Stow, pkgsrc и т. д., а также инструменты, специфичные для Python (pyenv).
В качестве наглядного примера предположим, что у вас есть пакет программного обеспечения, который поддерживает пять различных основных платформ (Windows, MacOS, современные системы Linux и некоторые старые UNIX). Его сценарий конфигурации будет содержать тесты, которые, как ожидается, будут проходить только в Windows, тесты, которые, как ожидается, будут проходить только в современном Linux, тесты, которые, как ожидается, будут проходить только в устаревших UNIX и т. д. - так что на любой данной платформе может быть только один из Ожидается, что пять тестов, специфичных для libc, пройдут успешно, а остальные задуманы и желательны, чтобы они провалились.
@CharlesDuffy Просто на этапе проверки не получается. Я могу настроить make install Python 3.10.14, но не Python 3.11.
... таким образом, autoconf, записывая заголовочный файл, может устанавливать флаги, отражающие только те возможности и режимы использования, которые действительно доступны для данной платформы.
Хорошо, но (например) тест gcc -qversion провалится в 3.10.14 так же, как и в 3.11; когда вы просто добавляете в вопрос случайные ошибки, не выяснив, какая конкретная ошибка приводит к сбою всего процесса настройки, вы не делаете ничего, что помогло бы нам сосредоточиться на проблеме.
Вот почему я (настоятельно!) рекомендую использовать Nix — когда вы говорите Nix установить Python 3.11, он не будет повторно использовать копию gcc, TCL и других зависимостей, поставляемых Ubuntu, а вместо этого установит свою собственную, полностью автономную версию. цепочка зависимостей (если он вообще должен выполнять локальную компиляцию и не может просто загружать двоичные файлы), поэтому то, что основано на Nix в одном дистрибутиве, будет построено на любом другом; это избавляет нас от необходимости выяснять, что в вашей системе отличается, а также выявлять и устранять конкретную точку сбоя.
В любом случае, если вы собираетесь попытаться исправить это в существующем дистрибутиве без набора параллельных зависимостей, начните с просмотра журналов, выводимых configure при его запуске — не config.log, а содержимого, записанного в stdout/stderr. Только если что-то в выводе сценария настройки является неожиданным, обратитесь к config.log, чтобы узнать подробности того, почему произошла эта конкретная непредвиденная вещь.
Я понимаю, что вы имеете в виду. Так что эти ошибки типичны, победить их все невозможно. В версии 3.11 папка bin пуста, а папки lib нет. Как узнать источник проблемы?
Давайте вернемся назад: действительно ли при запуске ../configure произошла ошибка? (Если он сгенерировал make-файлы, то ошибки не было, поэтому мы можем пройти мимо него). Если ошибки не было, какие логи создаются при запуске make?
(хотя на самом деле позвольте мне повторить мой совет: не создавайте свои собственные пакеты — используйте инструмент, который сделает это за вас).
@Чарльз Даффи. Я считаю, что проблемы возникают во время make install процесса. Я обновил свой вопрос этим. Помогут ли они вам в диагностике проблемы?
Да, это очень помогает. Мы знаем, что это ошибка времени компоновки, мы знаем, что это связано с инфраструктурой покрытия кода gcov. Есть ли флаг конфигурации для отключения поддержки gcov? Если да, то сначала make clean, а затем переконфигурируйте с помощью аргумента командной строки, чтобы явно отключить gcov.
(имейте в виду, что если вы не знаете, что начали с полностью чистого дерева, make clean может решить проблему самостоятельно — если, скажем, от предыдущей попытки сборки уже остались некоторые объектные файлы, для которых явно было включено покрытие. В проект меньшего размера, конечно не Python, иногда небрежный сопровождающий даже по ошибке оставляет объектные файлы в архиве с опубликованным исходным кодом)
@CharlesDuffy Я решил свою проблему и разместил ответ внутри своего вопроса, поскольку мой вопрос был закрыт другим. Если возможно, пожалуйста, помогите повторно открыть мой вопрос, чтобы я мог перенести свой ответ в раздел «Ответ». Спасибо.
Я до сих пор не очень уверен, что ответ будет полезен другим: обходной путь не является основной причиной, а без основной причины мы не знаем, насколько распространена проблема или какая группа людей имеет подобные симптомы. заявленное решение поможет, но тем не менее проголосовать за возобновление работы.
Ответы 1
После долгих проб и ошибок я выяснил причину. Моей последней команды было недостаточно. Эта командная строка:
make -j$(nproc) DESTDIR=/home/user/project/myapp.AppDir install
вместо этого должно быть:
make -j$(nproc)
make -j$(nproc) DESTDIR=/home/user/project/myapp.AppDir install
или
make -j$(nproc) && make -j$(nproc) DESTDIR=/home/user/project/myapp.AppDir install
Кроме того, согласно документации:
Предупреждение
make installможет перезаписать или замаскировать двоичный файл python3. поэтому рекомендуется использоватьmake altinstallвместоmake install, поскольку он только устанавливаетexec_prefix/bin/pythonversion.
Таким образом, при необходимости вместо make altinstall можно использовать make install.
Autoconf намеренно вызывает ошибки, чтобы проверить, какие версии зависимостей у вас есть и как эти зависимости ведут себя. Во-первых, невозможно и нежелательно, чтобы каждый тест в скрипте конфигурации проходил успешно, поэтому выбор случайного подмножества таких тестов и размещение их в сообщении здесь никому не пригодится.