크로스 컴파일러

프로그램 실행
일반적인 개념
코드 번역. 컴파일러 컴파일 시간 컴파일러 최적화 중간 표현(IR) 실행 런타임 시스템 런타임 실행 파일 통역사 가상 머신
코드의 종류
소스 코드 오브젝트 코드 바이트 코드 기계코드 마이크로코드
컴파일 전략
저스트 인 타임(JIT) 적시 추적 선행 시간(AOT) 변환 컴파일 재컴파일
주목할 만한 런타임
Android 런타임(ART) 공통 언어 런타임(CLR) 및 모노 crt0 Java 가상 머신(JVM) 목표-C 및 스위프트 V8 및 Node.js CPython 및 PyPy Zend 엔진(PHP) LuaJIT (Lua)
주목할 만한 컴파일러 및 툴 체인
GNU 컴파일러 컬렉션(GCC) LLVM과 Clang
v t

크로스 컴파일러는 컴파일러가 실행되고 있는 플랫폼 이외의 플랫폼용으로 실행 가능한 코드를 작성할 수 있는 컴파일러입니다.예를 들어 PC에서 실행되지만 Android 스마트폰에서 실행되는 코드를 생성하는 컴파일러는 크로스 컴파일러입니다.

크로스 컴파일러는 하나의 개발 호스트에서 여러 플랫폼의 코드를 컴파일할 때 유용합니다.예를 들어 컴퓨팅 리소스가 제한된 임베디드 시스템에서는 타깃 플랫폼에서 직접 컴파일하지 못할 수 있습니다.

크로스 컴파일러는 소스 간 컴파일러와는 다릅니다.크로스 컴파일러는 머신 코드의 크로스 플랫폼소프트웨어 생성을 위한 것이며 소스-투-소스 컴파일러는 텍스트 코드의 코딩 언어를 번역합니다.둘 다 프로그래밍 도구입니다.

사용하다

크로스 컴파일러의 기본적인 용도는 빌드 환경과 타깃 환경을 분리하는 것입니다.이것은, 몇개의 상황에서 도움이 됩니다.

• 장치에 리소스가 매우 제한된 임베디드 시스템입니다.예를 들어, 전자레인지에는 키패드와 도어 센서를 읽고, 디지털 디스플레이와 스피커에 출력을 제공하며, 음식을 조리하기 위한 전자레인지를 제어할 수 있는 매우 작은 컴퓨터가 있을 것이다.일반적으로 이 컴퓨터는 컴파일러, 파일 시스템 또는 개발 환경을 실행할 만큼 강력하지 않습니다.
• 여러 시스템에 대해 컴파일 중입니다.예를 들어 기업은 여러 버전의 운영체제를 지원하거나 여러 버전의 운영체제를 지원하고자 할 수 있습니다.크로스 컴파일러를 사용하면 이러한 타겟별로 컴파일할 수 있도록 단일 빌드 환경을 설정할 수 있습니다.
• 서버 팜에서의 컴파일여러 머신의 컴파일과 마찬가지로 많은 컴파일 작업을 수반하는 복잡한 빌드는 기본 하드웨어나 실행 중인 운영 체제 버전에 관계없이 사용 가능한 머신에서 실행할 수 있습니다.
• 새로운 플랫폼으로의 부트스트래핑새로운 플랫폼 또는 미래 플랫폼의 에뮬레이터용 소프트웨어를 개발할 때는 크로스 컴파일러를 사용하여 운영체제나 네이티브 컴파일러와 같은 필요한 도구를 컴파일합니다.
• 현재 플랫폼에서 실행되는 크로스 컴파일러(Windows XP에서 실행되는 Aztec C의 MS-DOS 6502 크로스 컴파일러 등)를 사용하는 애호가들이 Commodore 64나 Apple II와 같은 오래된 플랫폼의 에뮬레이터 네이티브 코드를 컴파일합니다.

가상 머신(Java의 JVM 등)을 사용하면 크로스 컴파일러가 개발된 이유 중 일부를 해결할 수 있습니다.가상 시스템 패러다임을 사용하면 동일한 컴파일러 출력을 여러 대상 시스템에서 사용할 수 있지만 가상 시스템이 있는 컴퓨터에서만 컴파일된 프로그램을 실행할 수 있기 때문에 항상 이상적인 것은 아닙니다.

일반적으로 하드웨어 아키텍처는 다르지만(예를 들어 x86 컴퓨터상의 MIPS 아키텍처를 대상으로 하는 프로그램을 코딩하는 경우), FreeB를 컴파일할 때처럼 운영체제 환경만 다를 경우에도 크로스 컴파일을 사용할 수 있습니다.Linux의 SD 프로그램, 또는 시스템 라이브러리의 SD 프로그램(glibc 호스트에서 uClibc를 사용하여 프로그램을 컴파일하는 경우 등).

캐나다 십자

Canadian Cross는 다른 기계용 크로스 컴파일러를 만드는 기술로, 원래 기계는 대상 기계보다 훨씬 느리거나 편리하지 않습니다.머신 A, B, C가 3대 있는 경우 머신 A(예를 들어 IA-32 프로세서 상에서 Windows XP를 실행)를 사용하여 머신 B 상에서 실행되는 크로스 컴파일러(예를 들어 x86-64 프로세서 상에서 Mac OS X를 실행)를 구축하여 머신 C(예를 들어 ARM 프로세서 상에서 Android를 실행)의 실행 파일을 작성합니다.이 예에서 실제적인 이점은 머신 A는 느리지만 독자적인 컴파일러를 가지고 있는 반면 머신 B는 빠르지만 컴파일러가 전혀 없으며 머신 C는 컴파일러에 사용하기에는 실용적으로 느리다는 것입니다.

GCC와 함께 Canadian Cross를 사용하는 경우, 그리고 이 예시와 같이 4개의 컴파일러가 관련될 수 있습니다.

• 머신 A (1)의 독자적인 네이티브 컴파일러(Microsoft Visual Studio의 컴파일러 등)를 사용하여 머신 A (2)의 gcc 네이티브 컴파일러를 구축합니다.
• 머신 A (2)의 gcc 네이티브 컴파일러는 머신 A에서 머신 B (3)로의 gcc 크로스 컴파일러 구축에 사용됩니다.
• 머신 A에서 머신 B(3)로의 gcc 크로스 컴파일러는 머신 B에서 머신 C(4)로의 gcc 크로스 컴파일러 구축에 사용됩니다.

최종 결과 크로스 컴파일러(4)는 빌드 머신 A에서는 실행할 수 없습니다.대신 어플리케이션을 실행 가능한 코드로 컴파일하기 위해 머신 B에서 실행됩니다.그 후 머신 C로 복사되어 머신 C에서 실행됩니다.

예를 들어 NetBSD는 다음과 같은 이름의 POSIXUnix 쉘 스크립트를 제공합니다.build.sh먼저 호스트의 컴파일러와 함께 자체 툴체인을 구축합니다.이 툴체인은 크로스 컴파일러를 구축하여 시스템 전체를 구축하기 위해 사용됩니다.

캐나다 십자가라는 용어는 이 문제들이 논의되고 있을 당시 캐나다가 세 개의 국가 ^[1]정당을 가지고 있었기 때문에 생겨났다.

초기 크로스 컴파일러 연대표

이 섹션은 확장해야 합니다.추가함으로써 도움이 될 수 있습니다. (2012년 7월)

• 1979 – ALGOL 68C는 ZCODE를 생성하였습니다.이것에 의해, 컴파일러와 그 외의 ALGOL 68 애플리케이션을 대체 플랫폼으로 이식할 수 있게 되었습니다.ALGOL 68C 컴파일러를 컴파일하려면 약 120KB의 메모리가 필요합니다.Z80에서는 64KB 메모리가 너무 작아서 컴파일러를 실제로 컴파일할 수 없습니다.따라서 Z80의 경우 컴파일러 자체는 더 큰 CAP 기능 컴퓨터 또는 IBM System/370 메인프레임에서 교차 컴파일되어야 했습니다.

GCC 및 교차 컴파일

컴파일러의 프리 소프트웨어 집합인 GCC는 크로스 컴파일로 설정할 수 있습니다.다양한 플랫폼과 언어를 지원합니다.

GCC 에서는, 타겟 플랫폼 마다 바이너틸의 컴파일 된 카피를 사용할 수 있을 필요가 있습니다.특히 중요한 것은 GNU 어셈블러입니다.따라서 먼저 스위치로 바이너틸을 올바르게 컴파일해야 합니다.--target=some-target설정 스크립트로 송신됩니다.또, GCC는, 같은 설정으로 할 필요가 있습니다.--target선택.다음으로 binutils가 작성하는 툴을 경로에서 사용할 수 있는 경우 GCC를 정상적으로 실행할 수 있습니다(유닉스 계열 운영체제에서 bash를 사용하는 경우).

PATH=/path/to/binutils/bin:${PATH} 메이커

GCC를 크로스 컴파일하려면 타깃 플랫폼의 C 표준 라이브러리의 일부를 호스트 플랫폼에서 사용할 수 있어야 합니다.프로그래머는 완전한 C 라이브러리를 컴파일하는 것을 선택할 수 있지만, 이 선택은 신뢰할 수 없을 수 있습니다.대체 방법은 newlib를 사용하는 것입니다.newlib은 C 소스 코드를 컴파일하는 데 필요한 가장 중요한 컴포넌트만 포함하는 작은 C 라이브러리입니다.

GNU autotools 패키지(autoconf, automake, libtool)는 빌드 플랫폼, 호스트 플랫폼 및 타깃 플랫폼의 개념을 사용합니다.빌드 플랫폼은 컴파일러가 실제로 컴파일되는 곳입니다.대부분의 경우 빌드는 정의되지 않은 상태로 두어야 합니다(호스트에서 기본값이 됩니다).호스트 플랫폼은 출력이 다른 컴파일러인지 여부에 관계없이 항상 컴파일러의 출력 아티팩트가 실행되는 곳입니다.타깃 플랫폼은 크로스 컴파일러를 교차 컴파일할 때 사용되며 패키지가 생성하는 오브젝트 코드 유형을 나타냅니다.그렇지 않으면 타깃 플랫폼 설정은 무관합니다.^[2]예를 들어, Dreamcast에서 실행되는 비디오 게임을 교차 컴파일하는 것을 고려해 보십시오.게임이 컴파일되는 머신은 빌드 플랫폼이고 드림캐스트는 호스트 플랫폼입니다.host와 target이라는 이름은 사용 중인 컴파일러와 관련지어 아들과 ^[3]손자처럼 이동됩니다.

임베디드 Linux 개발자들이 일반적으로 사용하는 또 다른 방법으로는 GCC 컴파일러와 Scratchbox, Scratchbox2, PRoot 등의 특수 샌드박스의 조합이 있습니다.이러한 툴은 프로그래머가 추가 경로를 설정하지 않고도 필요한 툴, libc 및 라이브러리를 구축할 수 있는 "추적" 샌드박스를 만듭니다.또, 실제로 목적의 CPU(ARM 아키텍처등)로 동작하고 있다고 생각되도록, 런타임의 「속이기」를 실시하는 기능도 준비되어 있습니다.이를 통해 설정 스크립트등을 에러 없이 실행할 수 있습니다.Scratchbox는 "추출되지 않은" 메서드에 비해 실행 속도가 느리며, 호스트에 있는 대부분의 툴이 작동하려면 Scratchbox로 이동해야 합니다.

Manx Aztec C 크로스 컴파일러

뉴저지주 슈루즈베리의 Manx Software Systems는 1980년대부터 PC 및 Mac까지 다양한 플랫폼용 전문 개발자를 대상으로 C 컴파일러를 생산했습니다.

Manx의 Aztec C 프로그래밍 언어는 MS-DOS, Apple II, DOS 3.3 및 ProDOS, Commodore 64, Macintosh 68XXX^[4] 및 Amiga를 포함한 다양한 플랫폼에서 사용할 수 있었습니다.

1980년대부터 1990년대에 걸쳐 Manx Software Systems가 사라질 때까지 Aztec^[5] C의 MS-DOS 버전은 네이티브 모드 컴파일러로 제공되거나 Commodore^[6] 64 ^[7]및 Apple II를 포함한 다른 프로세서를 탑재한 다른 플랫폼의 크로스 컴파일러로 제공되었습니다.Aztec C에서는 MS-DOS 기반의 크로스 컴파일러를 포함한 인터넷 배포가 아직 존재합니다.그것들은 오늘날에도 여전히 사용되고 있다.

Manx의 Aztec C86, 네이티브 모드 8086 MS-DOS 컴파일러도 크로스 컴파일러였습니다.Commodore 64 및 Apple II용 Aztec C65 6502 크로스 컴파일러와 같은 다른 프로세서용 코드를 컴파일하지는 않았지만 16비트 8086 프로세서 패밀리용 당시 레거시 운영체제용 바이너리 실행파일을 만들었습니다.

IBM PC가 처음 소개되었을 때 CP/M-86과 PC DOS를 포함한 운영 체제 중에서 선택할 수 있었습니다.Aztec C86에는 IBM PC 운영 체제용 코드를 생성하기 위한 링크 라이브러리가 제공되었습니다.1980년대 이후 버전의 Aztec C86(3.xx, 4.x 및 5.xx)은 MS-DOS "transitory" 버전1 및 2에^[8] 대한 지원이 추가되어 Aztec C86이 종료될 때까지 목표로 했던 "baseline" MS-DOS 버전3 이후보다 덜 강력했습니다.

마지막으로, Aztec C86은 C 언어 개발자들에게 ROM 대응 "HEX" 코드를 생성할 수 있는 기능을 제공했으며, 이는 ROM 버너를 사용하여 8086 기반 프로세서로 직접 전송할 수 있습니다.반가상화는 오늘날 더 일반적일 수 있지만 장치 드라이버 개발이 개별 애플리케이션용 애플리케이션 프로그래머에 의해 종종 수행되고 새로운 장치가 가내 산업에 속했던 당시에는 낮은 수준의 ROM 코드를 만드는 방법이 더 일반적이었습니다.애플리케이션 프로그래머가 제조사의 지원 없이 하드웨어와 직접 인터페이스하는 것은 드문 일이 아닙니다.이 방법은 오늘날의 임베디드 시스템 개발과 비슷했습니다.

Thomas Fenwick과 James Goodnow II는 Aztec-C의 두 주요 개발자였다.펜윅은 나중에 마이크로소프트 윈도우즈 CE 커널 또는 NK("^[9]New Kernel")의 저자로 유명해졌다.

Microsoft C 크로스 컴파일러

초기 역사 – 1980년대

Microsoft C(MSC)는 1980년대 이후의 다른 제품보다^[10] 역사가 짧습니다.최초의 마이크로소프트 C 컴파일러는 마이크로소프트가 ^[11]자체 제작한 첫 번째 버전인 MSC 4가 출시되기 전까지 래티스 C를 만든 같은 회사에서 만들어졌고 마이크로소프트에 의해 자체 브랜드로 바뀌었다.

1987년, 많은 개발자들이 마이크로소프트 C로 전환하기 시작했고, 더 많은 개발자들이 마이크로소프트 윈도우즈를 개발하면서 현재의 상태로 이어질 것입니다.Clipper나 나중에 Clarion과 같은 제품이 등장하여 크로스 언어 기술을 사용하여 데이터베이스 애플리케이션을 쉽게 개발할 수 있게 되었고, 프로그램의 일부를 Microsoft C로 컴파일할 수 있게 되었습니다.

Borland C(캘리포니아 회사)는 마이크로소프트가 첫 번째 C 제품을 출시하기 몇 년 전에 구입이 가능했습니다.

Borland보다 훨씬 전에 BSD Unix(Berkeley University)는 C 언어의 저자로부터 C를 받았습니다.AT&T(연구실)에서 일할 때 함께 쓴 Kernighan과 Ritchie.K&R의 원래 요구는 asm 1레벨의 구문 해석을 대체하기 위한 우아한 2레벨 구문일 뿐만 아니라 각 플랫폼을 지원하도록 최소한의 asm을 작성하도록 설계되어 있습니다(원래 C의 설계에서는 플랫폼별로 최소한의 지원 코드를 사용하여 교차 컴파일 할 수 있었습니다).또한 플랫폼 의존이 아닌 ASM 코드와 직접 관련된 어제 C.현재의 C(more-so c++)는 더 이상 C와 호환되지 않으며 기본이 되는 asm 코드는 특정 플랫폼에 기술된 것과 매우 다를 수 있습니다(Linux에서는 라이브러리 콜을 디스트리뷰터 선택으로 대체하거나 우회할 수 있습니다).오늘의 C는 3단계 또는 4단계 언어인데 2단계 언어처럼 옛날 방식으로 쓰입니다.

1987

C 프로그램은 어셈블리 언어로 작성된 모듈과 오랫동안 연결되어 있었습니다.대부분의 C 컴파일러(현재 컴파일러도 마찬가지)는 어셈블리 언어 패스를 제공합니다(효율성을 위해 조정한 후 어셈블리 후 나머지 프로그램과 링크할 수 있습니다).

Aztec-C와 같은 컴파일러는 모든 것을 어셈블리 언어로 변환한 후 코드를 독특한 경로로 조립하여 매우 효율적이고 작은 코드로 유명했지만 1987년에는 Microsoft C에 내장된 옵티마이저가 매우 우수하여 프로그램의 "미션 크리티컬" 부분만 재작성 대상으로 간주되었습니다.실제로 C 언어 프로그래밍은 "최저 수준" 언어로서 자리를 잡았고, 프로그래밍은 다학문적인 성장 산업이 되었고, 프로그래머가 사용자 인터페이스와 데이터베이스 인터페이스를 상위 언어로 작성하면서 더 큰 프로젝트가 이루어졌으며, 크로스 언어 개발의 필요성이 대두되어 오늘날까지 이어지고 있습니다.

1987년 MSC 5.1의 출시와 함께 마이크로소프트는 MS-DOS에 크로스 언어 개발 환경을 제공했습니다.16비트 바이너리 오브젝트 코드는 어셈블리 언어(MASM)와 QuickB를 포함한 마이크로소프트의 다른 언어로 작성되었습니다.ASIC, Pascal 및 Fortran은 "Mixed Language Programming" 및 "InterLanguage Calling"^[12]이라고 불리는 프로세스에서 하나의 프로그램으로 링크될 수 있습니다.이 믹스에서 BASIC을 사용하는 경우 가비지 수집에 필요한 BASIC을 컴파일하는 내부 런타임 시스템과 MS-DOS의 QBasic과 같은 BASIC 인터프리터를 시뮬레이트하는 기타 관리 작업을 지원하기 위해 메인 프로그램이 BASIC에 있어야 합니다.

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

이 기간 동안 마이크로소프트 C가 사용된 또 다른 유형의 교차 컴파일은 8088 기반 바코드 리더를 대상으로 한 링크 라이브러리를 제공하는 Symbol Technologies PDT3100(인벤토리 수집에 사용됨)과 같은 휴대용 장치가 필요한 소매 응용 프로그램에서 사용되었습니다.이 애플리케이션은 호스트 컴퓨터에 구축되어 실행 중인 핸드헬드 디바이스(시리얼 케이블 경유)로 전송되었습니다.이는 Symbola를 구입한 Motorola와 같은 회사가 Windows Mobile을 사용하여 현재 실행 중인 것과 유사합니다.

1990년대 초반

1990년대 내내 MSC 6(최초의 ANSI C 준거 컴파일러)을 시작으로 Microsoft는 C 컴파일러를 신흥 Windows 시장, OS/2 및 GUI 프로그램 개발에 다시 집중시켰습니다.MSC 6에서는 MS-DOS 측의 언어 혼재 호환성이 유지되었지만 Microsoft Windows 3.0 및 3.1용 API는 MSC 6으로 작성되었습니다.MSC 6은 32비트 어셈블리와 Windows XP의 기반이 되는 새로운 Windows NT를 지원하도록 확장되었습니다.단일 16비트 MS-DOS 애플리케이션에서 선호되던 정적 바인딩이 아닌 런타임 바인딩(동적 링크)을 이용한 16비트 및 32비트 프로그램 간 전달을 허용하기 위해 Thunk라는 프로그래밍 실행이 도입되었습니다.스태틱 바인딩은 일부 네이티브 코드 개발자에 의해 여전히 선호되고 있지만 일반적으로 CMM(Capability Matity Model)과 같은 새로운 베스트 프랙티스에 필요한 코드 재사용 정도는 제공하지 않습니다.

MS-DOS 지원은 C 프로그래밍 언어 및 MS-DOS와 하위 호환되며 16비트 및 32비트 코드 생성을 모두 지원하는 마이크로소프트 최초의 C++ 컴파일러 MSC 7 릴리스에서도 제공되었습니다.

MSC는 Aztec C86이 중단한 부분을 인계받았다.C 컴파일러의 시장점유율은 C와 C++를 하나의 번들로 제공하면서 10년이 지난 MS-DOS 시스템을 지원하는 크로스 컴파일러로 바뀌었고, Aztec C와 같은 컴파일러를 생산한 소규모 기업은 더 이상 경쟁할 수 없게 되었고 틈새 M으로 전환되었다.임베디드 시스템과 같은 아케트나 사라졌어요

MS-DOS 및 16비트 코드 생성 지원은 Microsoft C++ 및 Microsoft Application Studio 1.5에 번들된 MSC 8.00c까지 계속되었습니다.MSC는 현재 마이크로소프트가 제공하는 크로스 개발 환경인 Microsoft Visual Studio의 전신입니다.

1990년대 후반

MSC 12는 Microsoft Visual Studio 6과 함께 출시되었으며 MS-DOS 16비트 바이너리를 지원하지 않고 32비트 콘솔 애플리케이션을 지원하지만 Windows 95 및 Windows 98 코드 생성과 Windows NT를 지원했습니다. 링크 라이브러리는 Microsoft Windows를 실행하는 다른 프로세서에서 사용할 수 있었습니다.Microsoft가 지금까지도 계속하고 있는 것을 확인합니다.

MSC 13은 Visual Studio 2003과 함께 출시되었으며 MSC 14는 Visual Studio 2005와 함께 출시되었습니다.이들 둘 다 Windows 95와 같은 오래된 시스템용 코드를 아직 생성하지만 모바일 시장 및 ARM 아키텍처를 포함한 여러 타깃 플랫폼용 코드를 생성할 예정입니다.

.NET 이후

2001년에 마이크로소프트는 공통 언어 런타임(CLR)을 개발하여 의 핵심을 형성했습니다.Visual Studio IDE의 NET Framework 컴파일러.API 내의 이 운영체제 계층은 Windows 운영체제를 실행하는 플랫폼 간에 컴파일된 개발 언어를 혼재시킬 수 있습니다.

.NET Framework 런타임 및 CLR은 대상 시스템의 프로세서 및 장치에 대한 핵심 루틴에 매핑 계층을 제공합니다.Visual Studio의 명령줄 C 컴파일러는 다양한 프로세서의 네이티브 코드를 컴파일하여 코어 루틴을 빌드하는 데 사용할 수 있습니다.

Microsoft.ARM 아키텍처의 Windows Mobile과 같은 타깃 플랫폼용 NET 어플리케이션은 다양한 프로세서를 탑재한 Windows 머신과 Microsoft의 크로스 컴파일을 통해 에뮬레이터와 리모트 도입 환경도 제공하고 있습니다.이러한 환경은 과거 또는 다른 플랫폼에서의 크로스 컴파일러와는 달리 매우 적은 구성도 필요로 합니다.

Mono 등의 런타임 라이브러리는 크로스 컴파일의 호환성을 제공합니다.Linux 등의 다른 운영체제로의 NET 프로그램.

QT나 XVT를 포함한 이전 버전인 라이브러리는 Microsoft C를 사용하여 Windows 버전을 구축하면서 다른 플랫폼과의 소스 코드 레벨 교차 개발 기능을 제공합니다.MinGW와 같은 다른 컴파일러도 이 분야에서 인기를 끌고 있습니다.이는 소프트웨어 개발의 비 Windows 측을 구성하는 Unix와 보다 직접적으로 호환되기 때문에 개발자들은 익숙한 빌드 환경을 사용하여 모든 플랫폼을 대상으로 할 수 있기 때문입니다.

프리 파스칼

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

선택된 아키텍처 OS를 컴파일하려면 컴파일러 스위치(컴파일러 드라이버 fpc용) -P와 -T를 사용할 수 있습니다.이것은 컴파일러 자체를 크로스 컴파일 할 때도 행해집니다만, CPU_TARGET 와 OS_TARGET 의 make 옵션을 사용해 설정됩니다.Free Pascal 이 타겟 플랫폼에 아직 툴의 내부 버전을 가지고 있지 않은 경우는 타겟 플랫폼의 GNU 어셈블러와 링커가 필요합니다.

쨍그랑

Clang은 기본적으로 크로스 컴파일러이며 빌드 시 Clang이 대상으로 삼을 아키텍처를 선택할 수 있습니다.

「 」를 참조해 주세요.

• 최소 GW
• 스크래치 박스
• 프리 파스칼
• 크로스 어셈블러

레퍼런스

외부 링크

• 크로스 컴파일 도구– GNU 크로스 컴파일 도구 구성 레퍼런스
• gcc를 사용한 크로스 툴 체인 구축은 다른 GCC 크로스 컴파일 참조 Wiki입니다.
• Scratchbox는 Linux와 ARM 및 x86 타깃을 교차 컴파일하기 위한 툴킷입니다.
• Linux용 Grand Unified Builder(GUB)를 통해 여러 아키텍처를 교차 컴파일할 수 있습니다.다음은 예를 제시하겠습니다.GNU LilyPond에서 사용하는 Win32/Mac OS/FreeBSD/Linux
• Crossstool은 임베디드 시스템 등 원하는 아키텍처에 Linux 크로스 컴파일 환경을 구축하는 편리한 스크립트 툴 체인입니다.
• crosstool-NG는 Crossstool을 다시 쓴 것으로 툴 체인 구축에 도움이 됩니다.
• buildroot는 uClibc 기반의 툴체인을 구축하기 위한 스크립트세트로 보통 임베디드 시스템용입니다.OpenWrt에 의해 이용됩니다.
• ELDK(Embedded Linux Development Kit).Das U-Boot에서 사용.
• T2 SDE는 다양한 아키텍처의 GNU libC, uClibc 또는 dietlibc를 기반으로 Linux 시스템 전체를 구축하기 위한 또 다른 스크립트 세트입니다.
• Scratch 프로젝트에서 Linux를 횡단
• IBM은 GCC 툴 체인 교차 구축에 대한 매우 명확한 구조화된 튜토리얼을 가지고 있습니다.
• (프랑스어) 크로스 컴파일 avec GCC 4 sou Windows pour Linux - 크로스 GCC 툴체인을 구축하기 위한 튜토리얼이지만 Windows에서 Linux로 거의 개발되지 않은 주제입니다.