2011-05-08 4 views
5

Parece que no puedo importar ninguno de los módulos básicos ubicados en el directorio "lib-dynload". Están todos allí, pero obtengo el error: "ImportError: No module named X" cuando intento importarlos.Python compilado de forma cruzada no puede encontrar módulos básicos (matemática, operador, etc.)

Revisé mi sys.path e incluye el directorio donde se encuentran todos estos módulos y mi variable de entorno PYTHONHOME está configurada correctamente. Estoy un poco perdido en cuanto a cuál podría ser el problema. Información de fondo: se compila de forma cruzada desde el origen de Python 2.6.6 y se instala en una placa de Linux embebida de ARM con Angstrom.

Tenía python allí antes, había intentado hornearlo en la imagen pero le faltaban muchas cosas. Terminé haciendo todo lo posible para limpiar el árbol de directorios de todo lo que tuviera que ver con el pitón anterior antes de cargarlo en mi versión compilada cruzada.

Un strace de un simple script que simplemente intenta importar math: http://pastebin.com/3XgJ3nPR

Respuesta

2

veo ninguna comprobación en la que traza para nombres de archivo como math.so o mathmodule.so que podrían indicar que los objetos compartidos, los módulos se apagan por completo - que la La versión de Python que ha compilado no puede cargar módulos binarios de forma dinámica.

Más: mirando por encima de la config.out de mi generación más reciente de Python, veo varias líneas que Python está investigando si la plataforma permitirá que se carga de forma dinámica módulos binarios que terminan en .so:

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

Lo Qué dicen estas líneas en tu compilación cruzada?

+0

¿Sabía qué bandera o variable establecer para compilar de esta manera? Puedo verificar los resultados de make/setup/configure. – Jon

+0

No - cuando compilo Python en Ubuntu para i386, decide automáticamente que es capaz de cargar objetos compartidos. Tal vez comprueba la llamada al sistema 'dlopen()'? Sí, parece que sí. Actualizaré mi respuesta. –

+0

Lo comprueba en un par de lugares. Partes relevantes: http://pastebin.com/UQ2ZsteE. El resultado es fracaso. Este debe ser el problema, gracias. Veré cómo resolver esto, ¿alguna recomendación? FYI: Decidí cambiar los núcleos y la cadena de herramientas correspondiente recientemente, la cadena de herramientas anterior compiló python sin ningún problema. – Jon

0

Recientemente me he encontrado con un problema similar al construir Python 2.7.13, y creo que es this bug que se está reparando para Python 3 pero no se ha reintegrado a 2. El proceso de compilación (setup.py) genera una lista de módulos para compilar, y luego resta la lista de módulos incorporados (sys.builtin_module_names); sin embargo, setup.py se ejecuta (desde Makefile) usando python2.7 que en mi caso tomó el sistema binario (Ubuntu) en lugar del que se creó, por lo que resta los módulos que están incorporados para el sistema python (incluido el operador y colecciones) pero no para la que se está construyendo, por lo que no están incorporados ni se han construido como módulos externos.

Pude utilizar una sugerencia del error y anteponer el python construido, en el directorio de origen, a la ruta (y agregar un enlace simbólico de python2.7 -> python). Esto funcionó porque estaba construyendo un python x86 en una máquina x64 de varios arcos; si está compilando para otro sistema como ARM, puede necesitar aplicar el parche del error para obtener la lista de módulos incorporados de una etapa anterior del proceso de compilación, en lugar de hacerlo en el servidor de Python.

Cuestiones relacionadas