Compilación cruzada o compilación nativa para CPU Arch

arm native

Question

Cuando se escribe software que depende de la CPU, como el código C que se ejecuta en x86 o el código C que se ejecuta en ARM cpus. En general, hay dos formas de compilar este código, ya sea Cross-Compile al arco ARM de ARM (si está desarrollando en un sistema x86 por ejemplo) o copie su código a un sistema nativo arch cpu y compílelo ingenuamente.

Me pregunto si hay un beneficio para el enfoque nativo frente al enfoque de compilación cruzada. Noté que el equipo de ARM de Fedora está usando un clúster de compilación de dispositivos ARM de baja / lenta potencia para compilar "ingenuamente" su giro ARM de Fedora ... seguramente un proyecto respaldado por Red Hat tiene acceso a algunos potentes servidores de compilación que ejecutan x 86 cpus eso podría hacer el trabajo en la mitad del tiempo ... ¿por qué su elección? ¿Me estoy perdiendo algo mediante la compilación cruzada de mi software?

Answer 1

Depende mucho del compilador. ¿Cómo maneja la cadena de herramientas la diferencia entre la compilación nativa y cruzada? ¿Es simplemente un caso de la cadena de herramientas siempre piensa que se está construyendo como un compilador cruzado, pero una forma de construirlo es dejar que el script de configuración detecte automáticamente el host en lugar de hacerlo manualmente (y establecer automáticamente el prefijo, etc. )?

No asuma que solo porque está diseñado para ser un compilador nativo, es realmente nativo. Hay muchas instancias en las que las distros simplifican su compilador nativo (y kernel y otros binarios) para que esa distribución se ejecute en un rango más amplio de sistemas. En un sistema ARMv6 es posible que esté ejecutando un compilador que por defecto es ARMv4.

Eso plantea una pregunta similar a la tuya, si construyo la cadena de herramientas con una arquitectura por defecto, entonces especifico que otra es tan diferente que construir la cadena de herramientas para la arquitectura objetivo.

Lo ideal sería esperar que un compilador / cadena de herramientas en su mayoría depurada le daría los mismos resultados, ya sea que usted sea nativo o compilado cruzado e independiente de la arquitectura predeterminada. Ahora he visto en una versión anterior que el llvm-gcc cuando se ejecuta en un host de 64 bits, compilación cruzada para armar generaría todas las entradas como 64 bits añadiendo mucho al código, la misma versión del compilador, el mismo código fuente en un bit de 32 bits host daría resultados diferentes (32 bit ints). Básicamente, el modificador-m32 no funcionó para llvm-gcc (en ese momento), no sé si ese sigue siendo el caso, ya que cambié a clang cuando hago todo el trabajo y nunca volví a mirar hacia llvm-gcc ... llvm / clang por ejemplo, es en su mayoría un compilador cruzado todo el tiempo, el enlazador es lo único que parece ser específico del host, puede tomar un archivo llvm y compilar para cualquiera de los objetivos en cualquier sistema host (siempre que su compilación no haya desactivado ningún de los objetivos admitidos, por supuesto).

Answer 2

El único beneficio de compilar de forma nativa es que no tiene que transferir el programa a la plataforma de destino, ya que ya está allí.

Sin embargo, ese no es un beneficio tan grande cuando se considera que la mayoría de las plataformas de destino tienen una potencia masiva en comparación con una PC x86 moderna. Las cantidades de memoria, una CPU más rápida y, especialmente, discos mucho más rápidos hacen que los tiempos de compilación sean mucho más rápidos en una PC. Tanto que la ventaja de la construcción nativa ya no es una ventaja.

Answer 3

No técnicamente, no te falta nada mediante la compilación cruzada dentro del contexto de .c -> .o -> a.out (o lo que sea); Un compilador cruzado le dará el mismo binario que un compilador nativo (no obstante las versiones)

Las "ventajas" de construir de forma nativa provienen de pruebas posteriores a la compilación y administración de sistemas complejos.

1) Si puedo ejecutar pruebas unitarias rápidamente después de compilar, puedo acceder a cualquier error / problema rápidamente; el ciclo es presumiblemente más corto que el ciclo de compilación cruzada;

2) si estoy compilando un software de destino que tiene bibliotecas de terceros que usa, entonces construir, implementar y luego usarlas para construir mi objetivo probablemente sería más fácil en la plataforma nativa; No quiero lidiar con las compilaciones de compilación cruzada de esos porque la mitad de ellos tienen procesos de compilación escritos por monos locos que hacen que compilarlos sea difícil.

Por lo general, para la mayoría de las cosas uno intentaría llegar a una construcción base y compilar el resto de forma nativa. A menos que tenga una configuración enferma donde mi compilador cruzado sea súper perverso y yo el tiempo que ahorro allí, vale la pena la configuración necesaria para que el resto de las cosas (como pruebas de unidades y administración de dependencias) sea más fácil.

Al menos esos son mis pensamientos

Answer 4

El beneficio principal es que no se deben ./configure todas las secuencias de comandos ./configure cuando se ejecuta de forma nativa. Si está utilizando un rootfs shadow, entonces todavía tiene configuraciones ejecutando uname para detectar el tipo de CPU, etc. Por ejemplo, vea esta pregunta . pkgconfig y otras herramientas intentan facilitar la construcción cruzada , pero los paquetes normalmente obtienen primero la construcción nativa en x86 , y luego, tal vez , la construcción nativa en ARM . la construcción cruzada puede ser dolorosa ya que cada paquete puede necesitar ajustes individuales.

Finalmente, si realiza optimizaciones guiadas por perfiles y ejecuta suites de pruebas ^{según Joachim} , es prácticamente imposible hacerlo en un entorno de compilación cruzada .

La velocidad de compilación en ARM es significativamente más rápida que la de los creadores de paquetes humanos, configure lectura, edite configure , vuelva a ejecutar configure, compile, enlace de ciclos.

Esto también encaja bien con una estrategia de integración continua . Varios paquetes, especialmente bibliotecas , se pueden construir / implementar / probar rápidamente. La prueba de bibliotecas puede implicar cientos de paquetes dependientes. Por lo general, las distribuciones de Arm Linux necesitarán prototipos de cambios cuando se actualicen y apliquen parches a una biblioteca base que puede tener cientos de paquetes dependientes que al menos necesitan una nueva prueba. Un ciclo lento hecho por una computadora siempre es mejor que una compilación rápida seguida de intervención humana manual.