De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Ejecución del programa
Conceptos generales
Tipos de codigo
Estrategias de compilación
Tiempos de ejecución notables
Compiladores y cadenas de herramientas notables

Un compilador cruzado es un compilador capaz de crear código ejecutable para una plataforma distinta a aquella en la que se ejecuta el compilador. Por ejemplo, un compilador que se ejecuta en una PC con Windows 7 pero genera código que se ejecuta en un teléfono inteligente Android es un compilador cruzado.

Es necesario un compilador cruzado para compilar código para múltiples plataformas desde un host de desarrollo. La compilación directa en la plataforma de destino puede no ser factible, por ejemplo, en un microcontrolador de un sistema integrado , porque esos sistemas no contienen ningún sistema operativo. En la paravirtualización , una computadora ejecuta múltiples sistemas operativos y un compilador cruzado podría generar un ejecutable para cada uno de ellos desde una fuente principal.

Los compiladores cruzados son distintos de los compiladores de fuente a fuente . Un compilador cruzado es para el desarrollo de software multiplataforma de código de máquina, mientras que un compilador de fuente a fuente traduce de un lenguaje de programación a otro en código de texto. Ambas son herramientas de programación .

Utilice [ editar ]

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

  • Computadoras integradas donde un dispositivo tiene recursos extremadamente limitados. Por ejemplo, un horno de microondas tendrá una computadora extremadamente pequeña para leer su panel táctil y el sensor de la puerta, proporcionar salida a una pantalla digital y un altavoz, y controlar la maquinaria para cocinar alimentos. Esta computadora no será lo suficientemente poderosa para ejecutar un compilador, un sistema de archivos o un entorno de desarrollo. Dado que la depuración y las pruebas también pueden requerir más recursos de los que están disponibles en un sistema integrado, la compilación cruzada puede ser menos complicada y menos propensa a errores que la compilación nativa.
  • Compilación para varias máquinas. Por ejemplo, una empresa puede querer admitir varias versiones diferentes de un sistema operativo o admitir varios sistemas operativos diferentes. Mediante el uso de un compilador cruzado, se puede configurar un único entorno de compilación para compilar cada uno de estos objetivos.
  • Compilación en una granja de servidores . Al igual que la compilación para varias máquinas, una compilación complicada que implica muchas operaciones de compilación se puede ejecutar en cualquier máquina que sea gratuita, independientemente de su hardware subyacente o la versión del sistema operativo que esté ejecutando.
  • Bootstrapping a una nueva plataforma. Al desarrollar software para una nueva plataforma, o el emulador de una plataforma futura, se usa un compilador cruzado para compilar las herramientas necesarias, como el sistema operativo y un compilador nativo.
  • Compilación de código nativo para emuladores para plataformas más antiguas ahora obsoletas como Commodore 64 o Apple II por entusiastas que usan compiladores cruzados que se ejecutan en una plataforma actual (como los compiladores cruzados MS-DOS 6502 de Aztec C que se ejecutan en Windows XP ).

El uso de máquinas virtuales (como la JVM de Java ) resuelve algunas de las razones por las que se desarrollaron compiladores cruzados. El paradigma de la máquina virtual permite que se utilice la misma salida del compilador en varios sistemas de destino, aunque esto no siempre es ideal porque las máquinas virtuales suelen ser más lentas y el programa compilado solo se puede ejecutar en equipos con esa máquina virtual.

Normalmente, la arquitectura del hardware es diferente (por ejemplo, compilar un programa destinado a la arquitectura MIPS en una computadora x86 ), pero la compilación cruzada también es aplicable cuando solo difiere el entorno del sistema operativo , como cuando se compila un programa FreeBSD en Linux , o incluso solo la biblioteca del sistema. , como cuando se compilan programas con uClibc en un host glibc .

Cruz canadiense [ editar ]

El Cross Canadian es una técnica para la construcción de compiladores cruzados para otras máquinas. Dadas tres máquinas A, B y C, una usa la máquina A (por ejemplo, ejecutando Windows XP en un procesador IA-32 ) para construir un compilador cruzado que se ejecuta en la máquina B (por ejemplo, ejecutando Mac OS X en un procesador x86-64 ) para crear ejecutables para la máquina C (por ejemplo, ejecutar Android en un procesador ARM ). Al usar Canadian Cross con GCC, puede haber cuatro compiladores involucrados

  • 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 usa 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 un código ejecutable que luego se copiaría en la máquina C y se ejecutaría en la máquina C.

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

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

Cronología de los primeros compiladores cruzados [ editar ]

  • 1979 - ALGOL 68C generó ZCODE ; esto ayudó a portar el compilador y otras aplicaciones de ALGOL 68 a plataformas alternativas. Para compilar el compilador ALGOL 68C se requieren aproximadamente 120 KB de memoria. Con Z80, su memoria de 64 KB es demasiado pequeña para compilar el compilador. Entonces, para el Z80, el compilador en sí tuvo que compilarse de forma cruzada desde una computadora con capacidad CAP más grande o una computadora central IBM System / 370 .

GCC y compilación cruzada [ editar ]

GCC , una colección de compiladores de software gratuito , se puede configurar para compilación cruzada. Es compatible con muchas plataformas e idiomas.

GCC requiere que haya disponible una copia compilada de binutils para cada plataforma de destino. Especialmente importante es el ensamblador GNU . Por lo tanto, binutils primero debe compilarse correctamente con el conmutador --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 binutils crea, estén disponibles en la ruta , lo que se puede hacer usando lo siguiente (en sistemas operativos tipo UNIX con bash):

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

Cross-compilar GCC requiere que una porción de la plataforma de destino' s biblioteca estándar C estará disponible en la plataforma anfitrión . El programador puede optar por compilar la biblioteca C completa, pero esta opción podría no ser confiable. La alternativa es usar newlib , que es una pequeña biblioteca de C que contiene solo los componentes más esenciales necesarios para compilar el código fuente de C.

Los paquetes de autotools de GNU (es decir , autoconf , automake y libtool ) utilizan la noción de una plataforma de compilación , una plataforma de host y una plataforma de destino . La plataforma de compilación es donde se compila realmente el compilador. En la mayoría de los casos, la compilación debe dejarse sin definir (será el valor predeterminado del host). La plataforma de host es siempre donde se ejecutarán los artefactos de salida del compilador, ya sea que la salida sea de otro compilador o no. La plataforma de destino se utiliza cuando se compilan compiladores cruzados, representa qué tipo de código de objeto producirá el paquete; de lo contrario elLa configuración de la plataforma de destino es irrelevante. [2] Por ejemplo, considere la posibilidad de realizar una compilación cruzada de un videojuego que se ejecutará en un Dreamcast . La máquina donde se compila el juego es la plataforma de construcción, mientras que Dreamcast es la plataforma anfitriona . Los nombres de host y target son relativos al compilador que se está usando y cambiado como hijo y nieto . [3]

Otro método utilizado popularmente por los desarrolladores de Linux embebido implica la combinación de compiladores GCC con entornos sandbox especializados como Scratchbox , scratchbox2 o PRoot . Estas herramientas crean una caja de arena " chrooted " donde el programador puede crear las herramientas, libc y bibliotecas necesarias sin tener que establecer rutas adicionales. También se proporcionan funciones para "engañar" al tiempo de ejecución de modo que "crea" que realmente 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 se ejecuta más lentamente en comparación con los métodos "no chrootados", y la mayoría de las herramientas que están en el host deben moverse a Scratchbox para que funcionen.

Compiladores cruzados de Manx Aztec C [ editar ]

Manx Software Systems , de Shrewsbury , Nueva Jersey , produjo compiladores de C a partir de la década de 1980 dirigidos a desarrolladores profesionales para una variedad de plataformas que incluyen 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 , Macintosh 68XXX [4] y Amiga .

Desde la década de 1980 y continuando a lo largo de la de 1990 hasta la desaparición de Manx Software Systems, la versión MS-DOS de Aztec C [5] se ofreció como compilador en modo nativo o como compilador cruzado para otras plataformas con diferentes procesadores, incluido el Commodore 64 [6 ] y Apple II. [7] Todavía existen distribuciones de Internet para Aztec C, incluidos sus compiladores cruzados basados ​​en MS-DOS. Todavía están en uso hoy.

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

Cuando se introdujo por primera vez IBM PC, estaba disponible con una selección de sistemas operativos, CP / M-86 y PC DOS eran dos de ellos. Aztec C86 se proporcionó con bibliotecas de enlaces para generar código para ambos sistemas operativos IBM PC . A lo largo de la década de 1980, las versiones posteriores de Aztec C86 (3.xx, 4.xx y 5.xx) agregaron soporte para las versiones 1 y 2 "transitorias" de MS-DOS [8] y que eran menos robustas que las versiones "de base" de MS-DOS. versión 3 y posterior que Aztec C86 apuntó hasta su desaparición.

Por último, Aztec C86 proporcionó a los desarrolladores de lenguaje C la capacidad de producir código "HEX" compatible con ROM que luego podría transferirse usando un quemador de ROM directamente a un procesador basado en 8086. La paravirtualización puede ser más común hoy en día, pero la práctica de crear código ROM de bajo nivel era más común per cápita durante aquellos años en los que los programadores de aplicaciones solían realizar el desarrollo de controladores de dispositivos para aplicaciones individuales, y los nuevos dispositivos equivalían a una industria artesanal . No era raro que los programadores de aplicaciones interactuaran directamente con el hardware sin el apoyo del fabricante. Esta práctica era similar al desarrollo de sistemas integrados en la actualidad.

Thomas Fenwick y James Goodnow II fueron los dos principales desarrolladores de Aztec-C. Fenwick más tarde se hizo conocido como el autor del kernel de Microsoft Windows CE o NK ("New Kernel") como se llamaba entonces. [9]

Compiladores cruzados de Microsoft C [ editar ]

Historia temprana - década de 1980 [ editar ]

Microsoft C (MSC) tiene una historia más corta que otros [10] que se remontan a la década de 1980. Los primeros compiladores de Microsoft C fueron hechos por la misma compañía que hizo Lattice C y Microsoft los renombró como propios, hasta que se lanzó MSC 4, que fue la primera versión que Microsoft produjo. [11]

En 1987, muchos desarrolladores comenzaron a cambiar a Microsoft C, y muchos más seguirían durante el desarrollo de Microsoft Windows hasta su estado actual. Surgieron productos como Clipper y más tarde Clarion que ofrecían un fácil desarrollo de aplicaciones de bases de datos mediante el uso de técnicas de lenguaje cruzado, lo que permitió que parte de sus programas se compilaran con Microsoft C.

Borland C (empresa de California) estuvo disponible para su compra años antes de que Microsoft lanzara su primer producto C.

Mucho antes de Borland, BSD Unix (Universidad de Berkeley) había obtenido C de los autores del lenguaje C: Kernighan y Ritche, quienes lo escribieron al unísono mientras trabajaban para AT&T.(laboratorios). Las necesidades originales de K&R no eran solo una elegante sintaxis analizada de segundo nivel para reemplazar la sintaxis analizada de primer nivel de asm: se diseñó para que se escribiera una cantidad mínima de asm para admitir cada plataforma (el diseño original de C era la capacidad de compilar usando C con la código de soporte mínimo por plataforma, que necesitaban). También ayer C directamente relacionado con el código ASM donde no depende de la plataforma. El C de hoy (más bien c ++) ya no es compatible con C y el código asm subyacente puede ser extremadamente diferente al escrito en una plataforma determinada (en Linux: a veces reemplaza y desvía las llamadas a la biblioteca con opciones de distribuidor). El C de hoy es un idioma de tercer o cuarto nivel que se usa a la antigua como un idioma de segundo nivel.

1987 [ editar ]

Los programas en C llevaban mucho tiempo vinculados con módulos escritos en lenguaje ensamblador . La mayoría de los compiladores de C (incluso los compiladores actuales) ofrecen un pase de lenguaje ensamblador (que puede modificarse para mayor eficiencia y luego vincularse al resto del programa después del ensamblaje).

Los compiladores como Aztec-C convirtieron todo al lenguaje ensamblador como una pasada distinta y luego ensamblaron el código en una pasada distinta, y se destacaron por su código muy eficiente y pequeño, pero en 1987 el optimizador integrado en Microsoft C era muy bueno, y solo Las partes "críticas para la misión" de un programa generalmente se consideraban para reescribir. De hecho, la programación en lenguaje C se había convertido en el lenguaje de "nivel más bajo", con la programación convirtiéndose en una industria de crecimiento multidisciplinario y los proyectos cada vez más grandes, con programadores escribiendo interfaces de usuario e interfaces de base de datos en lenguajes de nivel superior, y había una necesidad. surgió para el desarrollo de idiomas cruzados que continúa hasta el día de hoy.

En 1987, con el lanzamiento de MSC 5.1, Microsoft ofrecía un entorno de desarrollo de lenguajes cruzados para MS-DOS. El código de objeto binario de 16 bits escrito en lenguaje ensamblador ( MASM ) y otros lenguajes de Microsoft, incluidos QuickBASIC , Pascal y Fortran, podrían vincularse en un solo programa, en un proceso que llamaron "Programación de lenguaje mixto" y ahora "Llamadas entre idiomas". [12] Si se usó BASIC en esta combinación, el programa principal debía estar en BASIC para soportar el sistema de ejecución interno que compilaba el BASIC requerido para la recolección de basura y sus otras operaciones administradas que simulaban un intérprete de BASIC como QBasic en MS-DOS.

La convención de llamada para el código C, en particular, era pasar parámetros en "orden inverso" en la pila y devolver valores en la pila en lugar de en un registro de procesador . Había otras reglas de programación para hacer que todos los lenguajes funcionaran juntos, pero esta regla en particular persistió a través del desarrollo de lenguajes cruzados que continuó en las versiones de Windows de 16 y 32 bits y en el desarrollo de programas para OS / 2 , y que persiste en este día. Se conoce como la convención de llamadas de Pascal .

Otro tipo de compilación cruzada para el que se utilizó Microsoft C durante este tiempo fue en aplicaciones minoristas que requieren dispositivos de mano como el PDT3100 de Symbol Technologies (utilizado para hacer inventario ), que proporciona una biblioteca de enlaces dirigida a un lector de códigos de barras basado en 8088 . La aplicación se construyó en la computadora host y luego se transfirió al dispositivo de mano (a través de un cable serial ) donde se ejecutó, similar a lo que se hace hoy para ese mismo mercado usando Windows Mobile por compañías como Motorola , que compraron Symbol.

Principios de la década de 1990 [ editar ]

A lo largo de la década de 1990 y comenzando con MSC 6 (su primer compilador compatible con ANSI C ), Microsoft volvió a enfocar sus compiladores de C en el mercado emergente de Windows, y también en OS / 2 y en el desarrollo de programas GUI . La compatibilidad de idiomas mixtos se mantuvo a través de MSC 6 en el lado de MS-DOS, pero la API para Microsoft Windows 3.0 y 3.1 se escribió en MSC 6. MSC 6 también se extendió para brindar soporte para ensamblados de 32 bits y soporte para Windows for Workgroups emergente y Windows NT, que formaría la base de Windows XP . Una práctica de programación llamada thunkse introdujo para permitir el paso entre programas de 16 y 32 bits que aprovechaban el enlace en tiempo de ejecución (enlace dinámico ) en lugar del enlace estático que se favorecía en las aplicaciones monolíticas de MS-DOS de 16 bits. Algunos desarrolladores de código nativo todavía prefieren el enlace estático, pero generalmente no proporciona el grado de reutilización de código requerido por las mejores prácticas más recientes, como el modelo de madurez de capacidad (CMM).

El soporte de MS-DOS todavía se proporcionó con el lanzamiento del primer compilador de C ++ de Microsoft, MSC 7, que era compatible con versiones anteriores del lenguaje de programación C y MS-DOS y admitía la generación de código de 16 y 32 bits.

MSC asumió el control donde lo dejó Aztec C86 . La cuota de mercado de los compiladores de C se había convertido en compiladores cruzados que aprovechaban las últimas y mejores características de Windows, ofrecían C y C ++ en un solo paquete y seguían admitiendo sistemas MS-DOS que ya tenían una década, y las empresas más pequeñas que Los compiladores producidos como Aztec C ya no podían competir y se dirigieron a nichos de mercado como los sistemas integrados o desaparecieron.

El soporte de generación de código de 16 bits y MS-DOS continuó hasta MSC 8.00c, que se incluía con Microsoft C ++ y Microsoft Application Studio 1.5, el precursor de Microsoft Visual Studio, que es el entorno de desarrollo cruzado que Microsoft ofrece en la actualidad.

Finales de la década de 1990 [ editar ]

MSC 12 se lanzó con Microsoft Visual Studio 6 y ya no proporcionó soporte para binarios de 16 bits de MS-DOS, sino que proporcionó soporte para aplicaciones de consola de 32 bits, pero proporcionó soporte para la generación de código de Windows 95 y Windows 98 , así como para Windows NT . Las bibliotecas de enlaces estaban disponibles para otros procesadores que ejecutaban Microsoft Windows; una práctica que Microsoft continúa hasta el día de hoy.

MSC 13 se lanzó con Visual Studio 2003 y MSC 14 se lanzó con Visual Studio 2005 , los cuales todavía producen código para sistemas más antiguos como Windows 95, pero que producirán código para varias plataformas de destino, incluido el mercado móvil y la arquitectura ARM .

.NET y más [ editar ]

En 2001, Microsoft desarrolló Common Language Runtime (CLR), que formó el núcleo de su compilador .NET Framework en Visual Studio IDE. Esta capa del sistema operativo que se encuentra en la API permite la combinación de lenguajes de desarrollo compilados en plataformas que ejecutan el sistema operativo Windows.

El tiempo de ejecución de .NET Framework y CLR proporcionan una capa de mapeo a las rutinas centrales para el procesador y los dispositivos en la computadora de destino. El compilador C de la línea de comandos en Visual Studio compilará código nativo para una variedad de procesadores y se puede usar para construir las rutinas centrales ellos mismos.

Las aplicaciones de Microsoft .NET para plataformas de destino como Windows Mobile en la arquitectura ARM se compilan de forma cruzada en máquinas Windows con una variedad de procesadores y Microsoft también ofrece emuladores y entornos de implementación remota que requieren muy poca configuración, a diferencia de los compiladores cruzados de antaño o en el futuro. otras plataformas.

Las bibliotecas en tiempo de ejecución, como Mono , proporcionan compatibilidad para programas .NET compilados de forma cruzada con otros sistemas operativos, como Linux .

Bibliotecas como Qt y sus predecesores, incluido XVT, brindan capacidad de desarrollo cruzado a nivel de código fuente con otras plataformas, al mismo tiempo que utilizan Microsoft C para construir las versiones de Windows. Otros compiladores como MinGW también se han vuelto populares en esta área, ya que son más directamente compatibles con los Unix que comprenden el lado del desarrollo de software que no es de Windows, lo que permite a esos desarrolladores apuntar a todas las plataformas utilizando un entorno de compilación familiar.

Pascal libre [ editar ]

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 producir ejecutables (o solo archivos de 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 producir ejecutables para i386-linux, i386-win32, i386-go32v2 (DOS) y todos los demás sistemas operativos (consulte [13] ). Sin embargo, para compilar en otra arquitectura, primero se debe construir una versión de arquitectura cruzada del compilador. El ejecutable del compilador resultante tendría 'ross' adicional antes de la arquitectura de destino en su nombre. es decir, si el compilador está diseñado para apuntar a x64, entonces el ejecutable sería ppcrossx64.

Para compilar para un sistema operativo de arquitectura elegido, se puede utilizar el modificador de compilador (para el controlador del compilador fpc) -P y -T. Esto también se hace cuando se realiza una compilación cruzada del propio compilador, pero se establece mediante la opción make CPU_TARGET y OS_TARGET. Se requiere el ensamblador y enlazador GNU para la plataforma de destino si Free Pascal aún no tiene una versión interna de las herramientas para la plataforma de destino.

Clang [ editar ]

Clang es de forma nativa un compilador cruzado, en el momento de la compilación puede seleccionar las arquitecturas a las que desea que Clang pueda apuntar.

Ver también [ editar ]

  • MinGW
  • Scratchbox
  • Pascal libre
  • Ensamblador cruzado

Referencias [ editar ]

  1. ^ "4.9 cruces canadienses" . CrossGCC . Archivado desde el original el 9 de octubre de 2004 . Consultado el 8 de agosto de 2012 . Esto se llama "Cruz canadiense" porque en el momento en que se necesitaba un nombre, Canadá tenía tres partidos nacionales.
  2. ^ https://www.gnu.org/s/libtool/manual/automake/Cross_002dCompilation.html
  3. ^ https://mesonbuild.com/Cross-compilation.html
  4. ^ "Computadoras Macintosh obsoletas" . Archivado desde el original el 26 de febrero de 2008 . Consultado el 10 de marzo de 2008 .
  5. ^ Azteca C
  6. ^ Comodoro 64
  7. ^ Apple II
  8. ^ Línea de tiempo de MS-DOS Archivado el 1 de mayo de 2008 en la Wayback Machine.
  9. ^ Dentro de Windows CE (busque Fenwick)
  10. ^ Historial de versiones de Microsoft Language Utility
  11. ^ Historia de compiladores de C basados ​​en PC Archivado el 15 de diciembre de 2007 en Wayback Machine
  12. ^ Qué versiones básicas pueden LLAMAR C, FORTRAN, Pascal, MASM
  13. ^ "Lista de plataformas compatibles con Free Pascal" . Lista de plataformas . Consultado el 17 de junio de 2010 . i386

Enlaces externos [ editar ]

  • Herramientas de compilación cruzada : referencia para configurar herramientas de compilación cruzada de GNU
  • La construcción de cadenas de herramientas cruzadas con gcc es una wiki de otras referencias de compilación cruzada de GCC
  • Scratchbox es un conjunto de herramientas para la compilación cruzada de Linux para objetivos ARM y x86
  • Grand Unified Builder (GUB) para Linux para compilar múltiples arquitecturas, por ejemplo: Win32 / Mac OS / FreeBSD / Linux utilizado por GNU LilyPond
  • Crosstool es una útil cadena de herramientas de scripts , que crea un entorno de compilación cruzada de Linux para la arquitectura deseada, incluidos los sistemas integrados.
  • 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 integrado) . 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 from Scratch
  • IBM tiene un tutorial estructurado muy claro sobre la construcción cruzada de una cadena de herramientas GCC.
  • (en francés) Compilación cruzada avec GCC 4 sous Windows pour Linux : un tutorial para construir una cadena de herramientas cruzada de GCC, pero de Windows a Linux, un tema que rara vez se desarrolla