Compilador cruzado

Un compilador cruzado es un compilador capaz de generar código ejecutable para una plataforma distinta a aquella en la que se ejecuta. Por ejemplo, un compilador que se ejecuta en un PC pero genera código que se ejecuta en dispositivos Android es un compilador cruzado.

Un compilador cruzado resulta útil para compilar código para múltiples plataformas desde un único entorno de desarrollo. La compilación directa en la plataforma de destino podría ser inviable, por ejemplo, en sistemas embebidos con recursos informáticos limitados.

Los compiladores cruzados se diferencian de los compiladores de código fuente a código fuente . Un compilador cruzado se utiliza para generar código máquina para software multiplataforma , mientras que un compilador de código fuente a código fuente traduce de un lenguaje de programación a otro en código de texto. Ambos son herramientas de programación .

El uso fundamental de un compilador cruzado es separar el entorno de compilación del entorno de destino. Esto resulta útil en varias situaciones:

• Los sistemas informáticos integrados se utilizan en dispositivos con recursos muy limitados. Por ejemplo, un horno microondas incorpora un microprocesador muy pequeño para leer su teclado y el sensor de la puerta, mostrar la información en una pantalla digital y un altavoz, y controlar el microondas para cocinar. Este microprocesador generalmente no tiene la potencia suficiente para ejecutar un compilador, un sistema de archivos o un entorno de desarrollo.
• Compilación para múltiples máquinas. Por ejemplo, una empresa puede querer dar soporte a varias versiones diferentes de un sistema operativo o a varios sistemas operativos distintos. Mediante un compilador cruzado, se puede configurar un único entorno de compilación para compilar para cada uno de estos sistemas.
• Compilación en un clúster de servidores . De forma similar a la compilación para varias máquinas, una compilación compleja que implica muchas operaciones de compilación puede ejecutarse en cualquier máquina disponible, independientemente de su hardware o de la versión del sistema operativo que ejecute.
• Adaptación a una nueva plataforma. Al desarrollar software para una nueva plataforma, o para el emulador de una plataforma futura, se utiliza un compilador cruzado para compilar las herramientas necesarias, como el sistema operativo y un compilador nativo.
• Compilación de código nativo para emuladores de plataformas antiguas ahora obsoletas como la Commodore 64 o la Apple II por parte de entusiastas que utilizan compiladores cruzados que se ejecutan en una plataforma actual (como los compiladores cruzados MS-DOS 6502 de Aztec C que se ejecutan bajo Windows XP ).

El uso de máquinas virtuales (como la JVM de Java ) resuelve algunos de los problemas que motivaron el desarrollo de compiladores cruzados. El paradigma de las máquinas virtuales permite utilizar la misma salida del compilador en múltiples sistemas de destino, aunque esto no siempre es ideal, ya que las máquinas virtuales suelen ser más lentas y el programa compilado solo puede ejecutarse en ordenadores que dispongan de dicha máquina virtual.

Normalmente, la arquitectura del hardware difiere (por ejemplo, al codificar un programa destinado a la arquitectura MIPS en un ordenador x86 ), pero la compilación cruzada también se puede utilizar cuando solo difiere el entorno del sistema operativo , como al compilar un programa FreeBSD en Linux , o incluso solo la biblioteca del sistema, como al compilar programas con uClibc en un host glibc .

La técnica Canadian Cross permite crear compiladores cruzados para otras máquinas, cuando la máquina original es mucho más lenta o menos conveniente que la máquina de destino. En este ejemplo, se utilizan tres máquinas A, B y C. Se puede usar la máquina A (por ejemplo, Windows XP en un procesador IA-32 ) para crear un compilador cruzado que se ejecute en la máquina B (por ejemplo, macOS en un procesador x86-64 ) y genere ejecutables para la máquina C (por ejemplo, Android en un procesador ARM ). La ventaja práctica radica en que la máquina A es lenta pero cuenta con un compilador propietario, mientras que la máquina B es rápida pero carece de compilador, y la máquina C es demasiado lenta para la compilación.

Al usar Canadian Cross con GCC, y como en este ejemplo, pueden intervenir cuatro compiladores.

• El compilador nativo propietario para la máquina A (1) (por ejemplo, el compilador de Microsoft Visual Studio ) se utiliza para construir el compilador nativo gcc para la máquina A (2) .
• El compilador nativo gcc para la máquina A (2) se utiliza para construir el compilador cruzado gcc de la máquina A a la máquina B (3).
• El compilador cruzado gcc de la máquina A a la máquina B (3) se utiliza para construir el compilador cruzado gcc de la máquina B a la máquina C (4)

El compilador cruzado de resultado final (4) no podrá ejecutarse en la máquina de compilación A; en su lugar, se ejecutaría en la máquina B para compilar una aplicación en código ejecutable que luego se copiaría a la máquina C y se ejecutaría en la máquina C.

Por ejemplo, NetBSD proporciona un script de shell POSIX Unixbuild.sh llamado que primero construirá su propia cadena de herramientas con el compilador del host; esto, a su vez, se utilizará para construir el compilador cruzado que se utilizará para construir todo el sistema.

El término Cruz Canadiense surgió porque en el momento en que se discutían estos temas, Canadá tenía tres partidos políticos nacionales. ^{[ 1 ]}

• 1969 – La primera versión de UNIX fue desarrollada por Ken Thompson en un PDP-7 , pero debido a la falta de herramientas y al costo, se compiló de forma cruzada en un sistema GECOS y se transfirió mediante cinta de papel . Esto demostró la viabilidad de la compilación cruzada para el desarrollo de sistemas operativos. ^{[ 2 ]}
• 1979 – ALGOL 68C generó ZCODE ; esto facilitó la portabilidad del compilador y otras aplicaciones de ALGOL 68 a plataformas alternativas. Para compilar el compilador de ALGOL 68C se requerían aproximadamente 120  KB de memoria. En el caso del Z80 , sus 64  KB de memoria eran insuficientes para compilar el compilador. Por lo tanto, para el Z80, el compilador debía compilarse de forma cruzada desde un ordenador con mayor capacidad CAP o un mainframe IBM System/370 .
• En la década de 1980, Aztec C ofrecía compilación nativa y cruzada para ordenadores domésticos como el Apple II y el Commodore 64 .

GCC , una colección de compiladores de software libre , se puede configurar para realizar compilación cruzada. Es compatible con numerosas plataformas y lenguajes de programación.

GCC requiere que haya una copia compilada de binutils disponible para cada plataforma de destino. El ensamblador GNU es especialmente importante . Por lo tanto, primero se debe compilar binutils correctamente con el parámetro --target=some-targetenviado al script de configuración . GCC también debe configurarse con la misma --targetopción. Luego, GCC se puede ejecutar normalmente siempre que las herramientas que crea binutils estén disponibles en la ruta , lo cual se puede hacer usando lo siguiente (en sistemas operativos tipo UNIX con bash):

PATH=/ruta/a/binutils/bin:${PATH} make

La compilación cruzada de GCC requiere que una parte de la biblioteca estándar de C de la plataforma de destino esté disponible en la plataforma anfitriona . El programador puede optar por compilar la biblioteca completa de C, pero esta opción podría ser poco fiable. La alternativa es usar newlib , una pequeña biblioteca de C que contiene solo los componentes esenciales necesarios para compilar código fuente de C.

Los paquetes GNU Autotools (es decir, autoconf , automake y libtool ) utilizan la noción de plataforma de compilación , plataforma anfitriona y plataforma de destino . La plataforma de compilación es donde se compila el compilador. En la mayoría de los casos, build debe dejarse sin definir (tomará por defecto host). La plataforma anfitriona es siempre donde se ejecutarán los artefactos de salida del compilador, independientemente de si la salida es otro compilador o no. La plataforma de destino se utiliza al realizar compilaciones cruzadas de compiladores cruzados; representa el tipo de código objeto que producirá el paquete; de ​​lo contrario, la configuración de la plataforma de destino es irrelevante. ^{[ 3 ]} Por ejemplo, consideremos la compilación cruzada de un videojuego que se ejecutará en una Dreamcast . La máquina donde se compila el juego es la plataforma de compilación, mientras que la Dreamcast es la plataforma anfitriona . Los nombres host y target son relativos al compilador que se utiliza y se desplazan como hijo y nieto . ^{[ 4 ]}

Otro método popular entre los desarrolladores de Linux embebido consiste en combinar compiladores GCC con entornos aislados especializados como Scratchbox y Scratchbox 2 , o PRoot . Estas herramientas crean un entorno aislado ( con chroot ) donde el programador puede compilar las herramientas, la biblioteca libc y las librerías necesarias sin tener que configurar rutas adicionales. También se proporcionan mecanismos para engañar al entorno de ejecución, haciéndole creer que se está ejecutando en la CPU de destino prevista (como una arquitectura ARM); esto permite que los scripts de configuración y similares se ejecuten sin errores. Scratchbox es más lento que los métodos sin chroot, y la mayoría de las herramientas del host deben trasladarse a Scratchbox para funcionar.

Manx Software Systems , con sede en Shrewsbury , Nueva Jersey , comenzó a producir compiladores de C en la década de 1980, dirigidos a desarrolladores profesionales para una variedad de plataformas, incluyendo ordenadores compatibles con IBM PC y Mac .

El lenguaje de programación Aztec C de Manx estaba disponible para una variedad de plataformas, incluyendo MS-DOS , Apple II , DOS 3.3 y ProDOS , Commodore 64 , Mac 68k ^{[ 5 ]} y Amiga .

Desde la década de 1980 y durante toda la década de 1990, hasta la desaparición de Manx Software Systems, la versión de Aztec C para MS-DOS ^{[ 6 ]} se ofreció tanto como compilador nativo como compilador cruzado para otras plataformas con diferentes procesadores, incluyendo el Commodore 64 ^{[ 7 ]} y el Apple II ^{[ 8 ]} . Todavía existen distribuciones de Aztec C en Internet, incluyendo sus compiladores cruzados para MS-DOS. Estas distribuciones siguen en uso hoy en día.

El Aztec C86 de Manx, su compilador MS-DOS para el 8086 en modo nativo , también era un compilador cruzado. Si bien no compilaba código para un procesador diferente como sus compiladores cruzados Aztec C65 6502 para el Commodore 64 y el Apple II, creaba ejecutables binarios para los sistemas operativos heredados de la época para la familia de procesadores 8086 de 16 bits.

Cuando se lanzó el IBM PC, estaba disponible con varios sistemas operativos, entre ellos CP/M-86 y PC DOS . Aztec C86 incluía bibliotecas de enlace para generar código para ambos sistemas operativos del IBM PC . A lo largo de la década de 1980, las versiones posteriores de Aztec C86 (3.xx, 4.xx y 5.xx) añadieron compatibilidad con las versiones "transitorias" 1 y 2 de MS-DOS ^{[ 9 ]} , que eran menos robustas que la versión "base" 3 y posteriores de MS-DOS, a las que Aztec C86 apuntaba hasta su desaparición.

Finalmente, Aztec C86 proporcionó a los desarrolladores de lenguaje C la capacidad de producir código HEX almacenable en ROM , que luego podía transferirse mediante una grabadora de ROM directamente a un procesador basado en 8086. Si bien la paravirtualización es más común hoy en día, la práctica de crear código ROM de bajo nivel era más frecuente per cápita durante aquellos años en que el desarrollo de controladores de dispositivos solía ser realizado por programadores de aplicaciones para aplicaciones individuales, y los nuevos dispositivos constituían una industria artesanal . No era raro que los programadores de aplicaciones interactuaran directamente con el hardware sin el soporte del fabricante. Esta práctica era similar al desarrollo de sistemas embebidos actual.

Thomas Fenwick y James Goodnow II fueron los dos principales desarrolladores de Aztec-C. Fenwick se hizo famoso más tarde como autor del núcleo de Microsoft Windows CE o NK ("Nuevo Núcleo"), como se le llamaba entonces. ^{[ 10 ]}

Free Pascal se desarrolló desde el principio como un compilador cruzado. El ejecutable del compilador (ppcXXX, donde XXX es una arquitectura de destino) es capaz de generar ejecutables (o simplemente archivos objeto si no existe un enlazador interno, o incluso solo archivos de ensamblaje si no existe un ensamblador interno) para todos los sistemas operativos de la misma arquitectura. Por ejemplo, ppc386 es capaz de generar ejecutables para i386-linux, i386-win32, i386-go32v2 (DOS) y todos los demás sistemas operativos (véase ^{[ 14 ]} ). Sin embargo, para compilar para otra arquitectura, primero se debe crear una versión cruzada del compilador. El ejecutable resultante del compilador tendrá 'ross' adicional antes de la arquitectura de destino en su nombre. Es decir, si el compilador se crea para x64, el ejecutable será ppcrossx64.

Para compilar para una arquitectura y sistema operativo específicos, se pueden usar las opciones -P y -T del controlador del compilador (fpc). Esto también se aplica al compilar el propio compilador de forma cruzada, pero se configura mediante las opciones CPU_TARGET y OS_TARGET de make. Se requiere el ensamblador y el enlazador de GNU para la plataforma de destino si Free Pascal aún no dispone de una versión interna de las herramientas para dicha plataforma.

Clang es un compilador cruzado por naturaleza; en tiempo de compilación, puede seleccionar las arquitecturas a las que desea que Clang pueda apuntar utilizando la -targetbandera. ^{[ 15 ]}

El sistema heterogéneo Plan 9 y su conjunto de herramientas no distinguen entre compilación cruzada y nativa. Los archivos Makefile son independientes de la arquitectura.

• MinGW
• Diagrama de lápida
• Caja de rascar 2
• Pascal libre
• Ensamblador cruzado

• Herramientas de compilación cruzada : referencia para configurar las herramientas de compilación cruzada de GNU.
• Building Cross Toolchains with gcc es una wiki de otras referencias sobre compilación cruzada de GCC.
• Scratchbox es un conjunto de herramientas para la compilación cruzada de Linux a arquitecturas ARM y x86.
• Grand Unified Builder (GUB) para Linux para compilar de forma cruzada múltiples arquitecturas, por ejemplo: Win32/Mac OS/FreeBSD/Linux, utilizado por GNU LilyPond.
• Crosstool es un útil conjunto de scripts que crean un entorno de compilación cruzada de Linux para la arquitectura deseada, incluidos los sistemas embebidos.
• crosstool-NG es una reescritura de Crosstool y ayuda a construir cadenas de herramientas.
• Buildroot es otro conjunto de scripts para construir una cadena de herramientas basada en uClibc , generalmente para sistemas embebidos. Es utilizado por OpenWrt .
• ELDK (Kit de desarrollo de Linux embebido) . Utilizado por Das U-Boot .
• T2 SDE es otro conjunto de scripts para construir sistemas Linux completos basados ​​en GNU libC, uClibc o dietlibc para una variedad de arquitecturas.
• Proyecto Cross Linux desde cero
• IBM dispone de un tutorial muy claro y estructurado sobre cómo compilar una cadena de herramientas GCC de forma cruzada.
• (en francés) Compilación cruzada con GCC 4 en Windows para Linux : un tutorial para construir una cadena de herramientas cruzada de GCC, pero de Windows a Linux, un tema poco desarrollado.