Кросс-скомпилированный Python не может найти базовые модули (математика, оператор и т. Д.)

Question

Я не могу импортировать какие-либо из основных модулей, расположенных в каталоге "lib-dynload". Они все есть, но я получаю ошибку: "ImportError: No module named X" при попытке их импортировать.

Я проверил свой sys.path, и он включает в себя каталог, в котором находятся все эти модули, и моя переменная окружения PYTHONHOME установлена ​​правильно. Я немного растерялся относительно того, в чем может быть проблема. Немного справочной информации: Это кросс-компилировано из исходного кода Python 2.6.6 и установлено на плате встроенного Linux ARM с Angstrom.

Раньше там был Python, я пытался запечь его в образе, но в нем пропало много вещей. В итоге я приложил все усилия, чтобы очистить дерево каталогов от всего, что связано с предыдущим питоном, перед загрузкой в ​​кросс-скомпилированную версию.

Часть простого скрипта, который просто пытается импортировать math: http://pastebin.com/3XgJ3nPR

Answer 1

Я не вижу проверок в этой трассировке для имен файлов, таких как math.so или mathmodule.so, которые могут указывать на то, что модули общего объекта полностью отключены - что скомпилированная версия Python не может загружать двоичные модули динамически.

Подробнее: просматривая config.out из моей последней сборки Python, я вижу несколько строк, в которых Python исследует, позволит ли платформа динамически загружать двоичные модули, заканчивающиеся .so:

checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking MACHDEP_OBJS... MACHDEP_OBJS

Что эти строки говорят о вашей кросс-компиляции?

Answer 2

Я недавно сталкивался с подобной проблемой сборки Python 2.7.13, и я считаю, что эта ошибка , которая исправлена ​​в Python 3, но не перенесена обратно на 2. Процесс сборки (настройка.py) генерирует список модулей для сборки, а затем вычитает список встроенных модулей (sys.builtin_module_names);однако, setup.py запускается (из Makefile) с использованием python2.7, который в моем случае взял двоичный файл системы (Ubuntu), а не встроенный, поэтому он вычитает модули, встроенные в системный питон (включаяоператор и коллекции), но не для того, который создается, поэтому они не являются ни встроенными, ни встроенными в качестве внешних модулей.

Мне удалось использовать предложение из ошибки и добавить встроенный питон в исходный кодкаталог, к пути (и добавить символическую ссылку из python2.7 -> python).Это сработало, потому что я собирал x86 python на многоархивном компьютере x64;если вы собираете для другой системы, такой как ARM, вам может потребоваться применить исправление из этой ошибки, чтобы получить список встроенных модулей более ранних в процессе сборки, а не хост-питон.