크로스 컴파일러

크로스 컴파일러(cross compiler)는 컴파일러의 실행 환경과 다른 플랫폼을 위한 실행 파일 코드를 생성할 수 있는 컴파일러이다. 예를 들어, PC에서 실행되지만 안드로이드 장치에서 실행되는 코드를 생성하는 컴파일러는 크로스 컴파일러이다.

크로스 컴파일러는 하나의 개발 호스트에서 여러 플랫폼용 코드를 컴파일하는 데 유용하다. 예를 들어 제한된 컴퓨팅 자원을 가진 임베디드 시스템에서는 대상 플랫폼에서 직접 컴파일하는 것이 불가능할 수 있다.

크로스 컴파일러는 소스 대 소스 컴파일러와는 다르다. 크로스 컴파일러는 크로스 플랫폼 소프트웨어의 기계어 코드 생성을 위한 것이고, 소스 대 소스 컴파일러는 하나의 코딩 언어에서 다른 언어로 텍스트 코드를 변환한다. 둘 다 프로그래밍 도구이다.

사용

크로스 컴파일러의 근본적인 용도는 빌드 환경과 대상 환경을 분리하는 것이다. 이는 여러 상황에서 유용하다.

• 임베디드 컴퓨터와 같이 장치에 자원이 매우 제한적인 경우. 예를 들어, 전자레인지에는 키패드와 도어 센서를 읽고, 디지털 디스플레이와 스피커로 출력을 제공하며, 음식을 조리하기 위해 마이크로파를 제어하는 매우 작은 컴퓨터가 있다. 이 컴퓨터는 일반적으로 컴파일러, 파일 시스템 또는 개발 환경을 실행할 만큼 강력하지 않다.
• 여러 기계용 컴파일. 예를 들어, 회사는 운영 체제의 여러 버전을 지원하거나 여러 다른 운영 체제를 지원할 수 있다. 크로스 컴파일러를 사용하면 단일 빌드 환경을 설정하여 각 대상에 대해 컴파일할 수 있다.
• 서버 팜에서 컴파일. 여러 기계용 컴파일과 유사하게, 많은 컴파일 작업을 포함하는 복잡한 빌드는 기본 하드웨어 또는 실행 중인 운영 체제 버전에 관계없이 사용 가능한 모든 기기에서 실행될 수 있다.
• 새로운 플랫폼으로 부트스트랩. 새로운 플랫폼 또는 미래 플랫폼의 에뮬레이터를 위한 소프트웨어를 개발할 때, 운영 체제 및 네이티브 컴파일러와 같은 필요한 도구를 컴파일하기 위해 크로스 컴파일러를 사용한다.
• 코모도어 64 또는 애플 II와 같이 현재는 구식인 플랫폼의 에뮬레이터용 네이티브 코드를 현재 플랫폼에서 실행되는 크로스 컴파일러(예: 윈도우 XP에서 실행되는 아즈텍 C의 MS-DOS MOS 6502 크로스 컴파일러)를 사용하는 애호가들이 컴파일하는 경우.

가상 머신(예: 자바의 자바 가상 머신)의 사용은 크로스 컴파일러가 개발된 일부 이유를 해결한다. 가상 머신 패러다임은 동일한 컴파일러 출력을 여러 대상 시스템에서 사용할 수 있도록 하지만, 가상 머신이 종종 느리고 컴파일된 프로그램이 해당 가상 머신이 있는 컴퓨터에서만 실행될 수 있기 때문에 항상 이상적이지는 않다.

일반적으로 하드웨어 아키텍처가 다르지만(예: X86 컴퓨터에서 MIPS 아키텍처용 프로그램을 코딩), 크로스 컴파일은 리눅스에서 FreeBSD 프로그램을 컴파일하는 경우처럼 운영체제 환경만 다른 경우에도 사용할 수 있으며, 심지어 Glibc 호스트에서 UClibc로 프로그램을 컴파일하는 경우처럼 시스템 라이브러리만 다른 경우에도 사용할 수 있다.

캐나디안 크로스

캐나디안 크로스는 원본 기계가 대상보다 훨씬 느리거나 불편할 때 다른 기계를 위한 크로스 컴파일러를 구축하는 기술이다. A, B, C 세 기계가 주어졌을 때, 기계 A(예: IA-32 프로세서에서 윈도우 XP 실행)를 사용하여 기계 B(예: X86-64 프로세서에서 MacOS 실행)에서 실행되는 크로스 컴파일러를 구축하여 기계 C(예: ARM 아키텍처 프로세서에서 안드로이드 실행)를 위한 실행 파일을 만든다. 이 예시에서 실질적인 이점은 기계 A는 느리지만 독점 컴파일러를 가지고 있고, 기계 B는 빠르지만 컴파일러가 전혀 없으며, 기계 C는 컴파일에 사용하기에 비실용적으로 느리다는 점이다.

GCC와 함께 캐나디안 크로스를 사용할 때, 이 예시와 같이 4개의 컴파일러가 관련될 수 있다.

• 기계 A용 독점 네이티브 컴파일러 (1) (예: 마이크로소프트 비주얼 스튜디오의 컴파일러)는 기계 A용 GCC 네이티브 컴파일러 (2)를 빌드하는 데 사용된다.
• 기계 A용 GCC 네이티브 컴파일러 (2)는 기계 A에서 기계 B로의 GCC 크로스 컴파일러 (3)을 빌드하는 데 사용된다.
• 기계 A에서 기계 B로의 GCC 크로스 컴파일러 (3)은 기계 B에서 기계 C로의 GCC 크로스 컴파일러 (4)를 빌드하는 데 사용된다.

최종 결과 크로스 컴파일러 (4)는 빌드 기계 A에서 실행될 수 없으며, 대신 기계 B에서 실행되어 애플리케이션을 실행 가능한 코드로 컴파일한 다음 기계 C로 복사하여 기계 C에서 실행된다.

예를 들어, NetBSD는 build.sh라는 POSIX 유닉스 셸 스크립트를 제공하는데, 이 스크립트는 먼저 호스트의 컴파일러로 자체 툴체인을 구축한다. 이것은 차례로 전체 시스템을 구축하는 데 사용될 크로스 컴파일러를 구축하는 데 사용된다.

캐나디안 크로스라는 용어는 이러한 문제가 논의될 당시 캐나다에 세 개의 정당이 있었기 때문에 생겨났다.^[1]

초기 크로스 컴파일러의 타임라인

• 1969년 – 켄 톰프슨은 PDP-7에서 UNIX의 첫 버전을 개발했지만, 도구 부족과 비용 때문에 GECOS 시스템에서 크로스 컴파일되어 천공 테이프를 통해 전송되었다. 이것은 OS 개발을 위한 실용적인 크로스 컴파일을 보여주었다.^[2]
• 1979년 – ALGOL 68C는 ZCODE를 생성했다. 이는 컴파일러 및 다른 ALGOL 68 응용 프로그램을 대체 플랫폼으로 이식하는 데 도움이 되었다. ALGOL 68C 컴파일러를 컴파일하려면 약 120 KB의 메모리가 필요했다. 자일로그 Z80은 64 KB 메모리가 너무 작아 실제로 컴파일러를 컴파일할 수 없었다. 그래서 Z80의 경우 컴파일러 자체는 더 큰 CAP 역량 컴퓨터 또는 IBM 시스템/370 메인프레임에서 크로스 컴파일되어야 했다.
• 1980년대 – Aztec C는 애플 II 및 코모도어 64와 같은 가정용 컴퓨터를 위한 네이티브 및 크로스 컴파일을 제공했다.

GCC 및 크로스 컴파일

GCC, 자유 소프트웨어 컴파일러 모음은 크로스 컴파일을 위해 설정할 수 있다. 많은 플랫폼과 언어를 지원한다.

GCC는 각 대상 플랫폼에 대해 컴파일된 binutils 사본이 필요하다. 특히 중요한 것은 GNU 어셈블러이다. 따라서 binutils는 먼저 configure 스크립트에 --target=some-target 스위치를 보내 올바르게 컴파일되어야 한다. GCC 또한 동일한 --target 옵션으로 구성되어야 한다. 그런 다음 binutils가 생성하는 도구들이 경로에 있을 경우 GCC는 일반적으로 실행될 수 있다. (유닉스 계열 운영체제에서 bash 사용 시):

PATH=/path/to/binutils/bin:${PATH} make

GCC를 크로스 컴파일하려면 대상 플랫폼의 C 표준 라이브러리 일부가 호스트 플랫폼에 있어야 한다. 프로그래머는 전체 C 라이브러리를 컴파일하도록 선택할 수 있지만, 이 선택은 신뢰할 수 없을 수 있다. 대안은 C 소스 코드를 컴파일하는 데 필요한 가장 필수적인 구성 요소만 포함하는 작은 C 라이브러리인 Newlib를 사용하는 것이다.

GNU Autotools 패키지 (즉, Autoconf, Automake, Libtool)는 빌드 플랫폼, 호스트 플랫폼, 대상 플랫폼의 개념을 사용한다. 빌드 플랫폼은 컴파일러가 실제로 컴파일되는 곳이다. 대부분의 경우 빌드는 정의되지 않은 상태로 두어야 한다 (호스트에서 기본값으로 설정된다). 호스트 플랫폼은 컴파일러의 출력 아티팩트가 실행될 곳이며, 출력이 다른 컴파일러인지 여부와는 상관없다. 대상 플랫폼은 크로스 컴파일러를 크로스 컴파일할 때 사용되며, 패키지가 생성할 객체 코드의 유형을 나타낸다. 그렇지 않으면 대상 플랫폼 설정은 관련이 없다.^[3] 예를 들어, 드림캐스트에서 실행될 비디오 게임을 크로스 컴파일하는 것을 고려해보자. 게임이 컴파일되는 기계는 빌드 플랫폼이고, 드림캐스트는 호스트 플랫폼이다. 호스트 및 대상 이름은 사용되는 컴파일러에 상대적이며 자식과 손자처럼 바뀐다.^[4]

임베디드 리눅스 개발자들이 일반적으로 사용하는 또 다른 방법은 GCC 컴파일러와 Scratchbox 및 Scratchbox 2, 또는 PRoot와 같은 특수 샌드박스의 조합을 포함한다. 이 도구들은 프로그래머가 추가 경로를 설정할 필요 없이 필요한 도구, libc 및 라이브러리를 구축할 수 있는 "Chroot" 샌드박스를 생성한다. 또한 런타임을 "속여" 의도한 대상 CPU(예: ARM 아키텍처)에서 실제로 실행되고 있다고 "믿게" 만드는 기능을 제공하여 구성 스크립트 등이 오류 없이 실행되도록 한다. Scratchbox는 "chroot되지 않은" 방법에 비해 느리게 실행되며, 호스트의 대부분의 도구는 작동하려면 Scratchbox로 옮겨져야 한다.

맨스 아즈텍 C 크로스 컴파일러

뉴저지, 슈루즈베리의 맨스 소프트웨어 시스템즈(Manx Software Systems)는 1980년대부터 IBM PC 호환기종 및 매킨토시를 포함한 다양한 플랫폼의 전문 개발자를 대상으로 C 컴파일러를 생산했다.

맨스의 Aztec C 프로그래밍 언어는 MS-DOS, 애플 II, DOS 3.3 및 ProDOS, 코모도어 64, Mac 68k^[5] 및 아미가를 포함한 다양한 플랫폼에서 사용할 수 있었다.

1980년대부터 1990년대 내내 맨스 소프트웨어 시스템즈가 사라질 때까지 Aztec C의 MS-DOS 버전^[6]은 네이티브 모드 컴파일러 또는 코모도어 64^[7] 및 애플 II^[8]와 같은 다른 프로세서를 가진 플랫폼을 위한 크로스 컴파일러로 제공되었다. Aztec C의 인터넷 배포판은 여전히 존재하며 MS-DOS 기반 크로스 컴파일러도 포함되어 있다. 이들은 오늘날에도 여전히 사용되고 있다.

맨스의 Aztec C86, 즉 네이티브 모드 8086 MS-DOS 컴파일러는 크로스 컴파일러이기도 했다. 코모도어 64 및 애플 II를 위한 Aztec C65 MOS 6502 크로스 컴파일러처럼 다른 프로세서용 코드를 컴파일하지는 않았지만, 당시 레거시 운영 체제인 16비트 8086 계열 프로세서용 이진 실행 파일을 생성했다.

IBM PC가 처음 도입되었을 때 CP/M-86과 PC DOS 두 가지 운영 체제를 선택할 수 있었다. Aztec C86은 두 IBM PC 운영 체제용 코드를 생성하기 위한 링크 라이브러리와 함께 제공되었다. 1980년대 내내 Aztec C86의 후기 버전(3.xx, 4.xx, 5.xx)은 MS-DOS "과도기" 버전 1과 2^[9]에 대한 지원을 추가했는데, 이 버전들은 Aztec C86이 사라질 때까지 목표로 했던 "기반" MS-DOS 버전 3 이후보다 견고성이 떨어졌다.

마지막으로, Aztec C86은 C 언어 개발자에게 ROM-able "HEX" 코드를 생성할 수 있는 기능을 제공했으며, 이 코드는 ROM 버너를 사용하여 8086 기반 프로세서로 직접 전송될 수 있었다. 반가상화가 오늘날 더 흔할 수 있지만, 저수준 ROM 코드를 생성하는 관행은 당시에는 장치 드라이버 개발이 종종 개별 애플리케이션을 위한 애플리케이션 프로그래머에 의해 이루어지고 새로운 장치가 수공업에 해당했던 시절에는 1인당 더 흔했다. 애플리케이션 프로그래머가 제조업체의 지원 없이 하드웨어와 직접 인터페이스하는 것이 드문 일이 아니었다. 이러한 관행은 오늘날의 임베디드 시스템 개발과 유사했다.

토마스 펜윅과 제임스 굿노우 2세는 Aztec-C의 주요 개발자였다. 펜윅은 나중에 마이크로소프트 윈도우 CE 커널 또는 당시 불렸던 NK("New Kernel")의 저자로 유명해졌다.^[10]

마이크로소프트 C 크로스 컴파일러

초기 역사 – 1980년대

마이크로소프트 C (MSC)는 다른 컴파일러보다 짧은 역사^[11]를 가지고 있으며 1980년대로 거슬러 올라간다. 최초의 마이크로소프트 C 컴파일러는 Lattice C를 만든 회사에서 만들었고, MSC 4가 출시될 때까지 마이크로소프트가 자체적으로 제작한 첫 번째 버전이었다.^[12]

1987년, 많은 개발자들이 마이크로소프트 C로 전환하기 시작했고, 마이크로소프트 윈도우의 현재 상태까지의 개발 과정에서 더 많은 개발자들이 따랐다. Clipper와 나중에 Clarion과 같은 제품들이 등장하여 크로스 언어 기술을 사용하여 프로그램의 일부를 마이크로소프트 C로 컴파일할 수 있도록 하여 쉬운 데이터베이스 애플리케이션 개발을 제공했다.

볼랜드 C (캘리포니아 회사)는 마이크로소프트가 첫 C 제품을 출시하기 몇 년 전부터 판매되었다.

1987년

C 프로그램은 오랫동안 어셈블리어로 작성된 모듈과 함께 링크되었다. 대부분의 C 컴파일러(심지어 현재 컴파일러도)는 어셈블리어 패스(효율성을 위해 조정된 다음 어셈블링 후 프로그램의 나머지 부분에 링크될 수 있음)를 제공한다.

Aztec-C와 같은 컴파일러는 모든 것을 별개의 패스로 어셈블리어로 변환한 다음 별개의 패스로 코드를 어셈블했으며, 매우 효율적이고 작은 코드로 유명했지만, 1987년까지 마이크로소프트 C에 내장된 최적화 프로그램은 매우 좋았고, 프로그램의 "미션 크리티컬" 부분만 일반적으로 다시 작성할 것으로 간주되었다. 사실, C 언어 프로그래밍은 "최하위" 언어로 자리 잡았고, 프로그래밍은 다학문적인 성장 산업이 되었고, 프로젝트는 더 커졌으며, 프로그래머들은 상위 수준 언어로 사용자 인터페이스와 데이터베이스 인터페이스를 작성했고, 오늘날까지 계속되는 크로스 언어 개발의 필요성이 대두되었다.

1987년, MSC 5.1 출시와 함께 마이크로소프트는 MS-DOS용 크로스 언어 개발 환경을 제공했다. 어셈블리어 (MASM)와 퀵베이직, 파스칼, 포트란을 포함한 마이크로소프트의 다른 언어로 작성된 16비트 이진 객체 코드는 "혼합 언어 프로그래밍" 또는 현재 "인터언어 호출"이라고 부르는 과정을 통해 하나의 프로그램으로 링크될 수 있었다.^[13] 이 혼합에 베이직이 사용된 경우, 메인 프로그램은 QBasic와 같은 인터프리터를 시뮬레이션하는 컴파일된 베이직이 필요로 하는 가비지 컬렉션 및 기타 관리 작업을 지원하기 위해 베이직으로 작성되어야 했다.

특히 C 코드의 호출 규약은 스택에 매개변수를 "역순"으로 전달하고 프로세서 레지스터가 아닌 스택에 반환 값을 전달하는 것이었다. 모든 언어가 함께 작동하도록 하는 다른 프로그래밍 규칙들이 있었지만, 이 특정 규칙은 윈도우 16비트 및 32비트 버전과 OS/2용 프로그램 개발 전반에 걸쳐 지속되었으며, 오늘날까지도 지속된다. 이는 파스칼 호출 규약으로 알려져 있다.

마이크로소프트 C가 이 시기에 사용된 또 다른 유형의 크로스 컴파일은 재고 관리에 사용되는 심볼 테크놀로지스 PDT3100과 같은 휴대용 기기를 필요로 하는 소매 애플리케이션에서였다. 이 기기는 8088 기반 바코드 판독기를 대상으로 하는 링크 라이브러리를 제공했다. 애플리케이션은 호스트 컴퓨터에서 빌드된 다음 직렬 케이블을 통해 휴대용 기기로 전송되어 실행되었으며, 이는 오늘날 모토로라와 같은 회사들이 윈도우 모바일을 사용하여 동일한 시장에서 수행하는 것과 유사하다.

1990년대 초반

1990년대 내내 그리고 MSC 6 (첫 ANSI C 준수 컴파일러)부터 시작하여 마이크로소프트는 C 컴파일러를 새로운 윈도우 시장, 그리고 OS/2 및 GUI 프로그램 개발에 다시 집중시켰다. 혼합 언어 호환성은 MS-DOS 측에서 MSC 6까지 유지되었지만, 마이크로소프트 윈도우 3.0 및 3.1용 API는 MSC 6으로 작성되었다. MSC 6은 또한 32비트 어셈블리에 대한 지원과 Windows for Workgroups 및 윈도우 NT와 같은 새로운 윈도우에 대한 지원을 제공하도록 확장되었으며, 이들은 윈도우 XP의 기반을 형성할 것이다. 썽크라는 프로그래밍 방식이 도입되어 런타임 바인딩(동적 링크)을 활용하여 16비트 및 32비트 프로그램 간의 전달을 허용했으며, 이는 모놀리식 16비트 MS-DOS 애플리케이션에서 선호되던 정적 링크와는 달랐다. 정적 링크는 여전히 일부 네이티브 코드 개발자들에게 선호되지만, 일반적으로 능력 성숙도 모델 (CMM)과 같은 새로운 모범 사례에서 요구되는 코드 재사용의 정도를 제공하지 않는다.

MS-DOS 지원은 마이크로소프트의 첫 C++ 컴파일러인 MSC 7 출시와 함께 계속 제공되었는데, 이 컴파일러는 C 프로그래밍 언어 및 MS-DOS와 하위 호환되며 16비트 및 32비트 코드 생성을 모두 지원했다.

MSC는 Aztec C86이 중단된 지점에서 바통을 이어받았다. C 컴파일러 시장 점유율은 최신 윈도우 기능을 활용하고, C와 C++를 단일 번들로 제공하며, 이미 10년이 지난 MS-DOS 시스템을 여전히 지원하는 크로스 컴파일러로 바뀌었고, Aztec C와 같은 컴파일러를 생산하던 소규모 회사들은 더 이상 경쟁할 수 없거나 임베디드 시스템과 같은 틈새 시장으로 전환하거나 사라졌다.

MS-DOS 및 16비트 코드 생성 지원은 Microsoft C++ 및 Microsoft Application Studio 1.5에 번들로 제공된 MSC 8.00c까지 계속되었는데, 이는 오늘날 마이크로소프트가 제공하는 크로스 개발 환경인 마이크로소프트 비주얼 스튜디오의 전신이다.

1990년대 후반

MSC 12는 마이크로소프트 비주얼 스튜디오 6과 함께 출시되었고 더 이상 MS-DOS 16비트 바이너리 지원을 제공하지 않고 32비트 콘솔 애플리케이션 지원을 제공했지만, 윈도우 95 및 윈도우 98 코드 생성뿐만 아니라 윈도우 NT 지원도 제공했다. 마이크로소프트 윈도우를 실행하는 다른 프로세서용 링크 라이브러리도 제공되었으며, 이는 마이크로소프트가 오늘날까지 계속하는 관행이다.

MSC 13은 비주얼 스튜디오 2003과 함께 출시되었고, MSC 14는 비주얼 스튜디오 2005와 함께 출시되었으며, 둘 다 윈도우 95와 같은 구형 시스템용 코드를 여전히 생성하지만, 모바일 시장 및 ARM 아키텍처를 포함한 여러 대상 플랫폼용 코드를 생성할 것이다.

.NET과 그 이후

2001년 마이크로소프트는 비주얼 스튜디오 IDE의 닷넷 프레임워크 컴파일러의 핵심을 형성하는 공통 언어 런타임 (CLR)을 개발했다. API에 있는 운영 체제의 이 계층은 윈도우 운영 체제를 실행하는 플랫폼 간에 컴파일된 개발 언어를 혼합할 수 있도록 한다.

닷넷 프레임워크 런타임과 CLR은 프로세서 및 대상 컴퓨터의 장치에 대한 핵심 루틴에 매핑 계층을 제공한다. 비주얼 스튜디오의 명령줄 C 컴파일러는 다양한 프로세서용 네이티브 코드를 컴파일하며, 핵심 루틴 자체를 구축하는 데 사용될 수 있다.

ARM 아키텍처의 윈도우 모바일과 같은 대상 플랫폼용 마이크로소프트 닷넷 애플리케이션은 다양한 프로세서를 가진 윈도우 머신에서 크로스 컴파일되며, 마이크로소프트는 또한 과거의 크로스 컴파일러나 다른 플랫폼과는 달리 매우 적은 구성만으로 에뮬레이터 및 원격 배포 환경을 제공한다.

모노와 같은 런타임 라이브러리는 크로스 컴파일된 닷넷 프로그램과 리눅스와 같은 다른 운영 체제 간의 호환성을 제공한다.

Qt 및 그 이전의 XVT와 같은 라이브러리는 소스 코드 수준에서 다른 플랫폼과의 크로스 개발 기능을 제공하며, 윈도우 버전을 빌드하는 데는 마이크로소프트 C를 계속 사용한다. MinGW와 같은 다른 컴파일러도 이 분야에서 인기를 얻었는데, 이는 소프트웨어 개발의 비윈도우 측을 구성하는 유닉스와 더 직접적으로 호환되어 개발자들이 익숙한 빌드 환경을 사용하여 모든 플랫폼을 대상으로 할 수 있기 때문이다.

프리 파스칼

프리 파스칼은 처음부터 크로스 컴파일러로 개발되었다. 컴파일러 실행 파일(ppcXXX, 여기서 XXX는 대상 아키텍처)은 동일한 아키텍처의 모든 OS에 대해 실행 파일(내부 링커가 없는 경우 객체 파일만, 내부 어셈블러가 없는 경우 어셈블리 파일만)을 생성할 수 있다. 예를 들어, ppc386은 i386-linux, i386-win32, i386-go32v2 (DOS) 및 기타 모든 OS용 실행 파일을 생성할 수 있다(참조^[14]). 그러나 다른 아키텍처로 컴파일하려면 먼저 컴파일러의 크로스 아키텍처 버전을 빌드해야 한다. 결과 컴파일러 실행 파일의 이름에는 대상 아키텍처 앞에 추가 'ross'가 붙는다. 즉, 컴파일러가 x64를 대상으로 빌드되면 실행 파일은 ppcrossx64가 된다.

선택한 아키텍처-OS용으로 컴파일하려면 컴파일러 스위치(컴파일러 드라이버 fpc용) -P 및 -T를 사용할 수 있다. 이는 컴파일러 자체를 크로스 컴파일할 때도 수행되지만, make 옵션 CPU_TARGET 및 OS_TARGET을 통해 설정된다. 프리 파스칼에 대상 플랫폼용 내부 도구 버전이 아직 없는 경우 대상 플랫폼용 GNU 어셈블러 및 링커가 필요하다.

클랭

클랭은 기본적으로 크로스 컴파일러이며, 빌드 시 클랭이 대상으로 할 아키텍처를 선택할 수 있다.

플랜 9

이질적인 시스템인 플랜 9 및 그 툴체인은 크로스 컴파일과 네이티브 컴파일을 구분하지 않는다. Makefile은 아키텍처에 독립적이다.

같이 보기

• MinGW
• 스크래치박스 2
• 프리 파스칼
• 크로스 어셈블러