크로스 컴파일러

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

크로스 컴파일러는 다른 아키텍처나 운영 체제에서 실행될 코드를 생성하는 데 사용되는 컴파일러이다. 주로 자원이 제한적인 임베디드 시스템, 다양한 플랫폼 지원, 서버 팜에서의 컴파일, 새로운 플랫폼 부트스트래핑, 구식 플랫폼 에뮬레이션 등에 활용된다. 크로스 컴파일러는 빌드 환경과 대상 환경을 분리하여 다양한 플랫폼을 지원하며, GCC, Free Pascal, Clang, Plan 9 등 다양한 종류가 존재한다. 캐나디안 크로스는 여러 대의 컴퓨터를 사용하여 크로스 컴파일러를 구축하는 기술을 의미하며, Microsoft C, Manx Aztec C 등도 크로스 컴파일러의 예시이다.

2. 사용

크로스 컴파일러는 빌드 환경과 대상 환경을 분리해야 하는 상황에서 유용하게 사용된다. 크로스 컴파일러가 유용한 경우는 다음과 같다.

임베디드 시스템: 임베디드 시스템은 자원이 매우 제한적이다. 예를 들어 전자레인지에 내장된 컴퓨터는 매우 작아서 컴파일러, 파일 시스템, 개발 환경을 실행하기 어렵다.
다양한 플랫폼 지원: 기업에서 여러 버전의 운영 체제를 지원하거나 여러 종류의 운영 체제를 지원해야 할 때, 크로스 컴파일러를 사용하면 단일 빌드 환경에서 각 대상에 맞게 컴파일할 수 있다.
서버 팜: 서버 팜 환경에서 복잡한 빌드를 수행할 때, 하드웨어나 운영 체제 버전에 관계없이 사용 가능한 모든 머신에서 컴파일을 실행할 수 있다.
새로운 플랫폼 부트스트래핑: 새로운 플랫폼이나 미래 플랫폼의 에뮬레이터를 위한 소프트웨어를 개발할 때, 운영체제 및 네이티브 컴파일러와 같은 필수 도구를 컴파일한다.
구식 플랫폼 에뮬레이션: Commodore 64나 애플 II와 같은 구형 플랫폼의 에뮬레이터를 위한 코드를 컴파일할 때도 사용된다.
가상 머신과의 관계: JVM과 같은 가상 머신은 크로스 컴파일러의 필요성을 일부 해결하지만, 속도가 느리고 해당 가상 머신이 있는 컴퓨터에서만 실행 가능하다는 단점이 있다.

일반적으로 아키텍처가 다른 경우(예: x86에서 MIPS 아키텍처용 프로그램 코딩)뿐만 아니라, 운영 체제 환경만 다른 경우(예: 리눅스에서 FreeBSD 프로그램 컴파일)에도 크로스 컴파일을 사용할 수 있다.^[1]

2. 1. 임베디드 시스템

임베디드 시스템과 같이 장치의 자원이 매우 제한적인 경우 크로스 컴파일러가 유용하다. 예를 들어, 전자레인지는 매우 작은 컴퓨터를 갖추고 있는데, 이 컴퓨터는 컴파일러, 파일 시스템 또는 개발 환경을 실행할 만큼 강력하지 않다. 따라서 더 강력한 시스템에서 크로스 컴파일을 수행하여 전자레인지와 같은 임베디드 시스템에서 실행될 코드를 개발한다.^[1]

2. 2. 다양한 플랫폼 지원

회사는 여러 버전의 운영 체제를 지원하거나 여러 종류의 운영 체제를 지원해야 할 때, 크로스 컴파일러를 사용하여 단일 빌드 환경을 설정하여 각 대상에 맞게 컴파일할 수 있다.^[1] 이는 특히 한국의 다양한 IT 환경에서 소프트웨어 호환성을 확보하는 데 중요한 역할을 한다. 예를 들어, 기업이 하나의 OS의 여러 버전을 지원하거나, 여러 OS를 지원하는 경우가 이에 해당한다.^[1]

2. 3. 서버 팜에서의 컴파일

여러 머신용 컴파일과 유사하게, 많은 컴파일 작업을 포함하는 복잡한 빌드는 기본 하드웨어나 실행 중인 운영 체제 버전에 관계없이 사용 가능한 모든 머신에서 실행할 수 있다.^[1] 서버 팜의 비교적 여유로운 머신에서 임의의 서버용 빌드를 수행한다.^[2]

2. 4. 새로운 플랫폼 부트스트래핑

새로운 플랫폼이나 미래 플랫폼의 에뮬레이터를 위한 소프트웨어를 개발할 때, 크로스 컴파일러를 사용하여 운영체제 및 네이티브 컴파일러와 같은 필수 도구를 먼저 컴파일한다.^[1]

2. 5. 구식 플랫폼 에뮬레이션

Commodore 64나 애플 II와 같은 구식이 된 이전 플랫폼의 에뮬레이터를 위한 네이티브 코드를 컴파일할 때 크로스 컴파일러를 사용한다. 예를 들어, Windows XP에서 실행되는 Aztec C의 MS-DOS 6502 크로스 컴파일러를 사용하는 경우가 있다.^[4]

2. 6. 가상 머신과의 관계

자바의 JVM과 같은 가상 머신은 크로스 컴파일러를 개발하는 동기가 되는 문제의 일부를 해결한다. 가상 머신은 하나의 컴파일러 출력을 여러 다른 시스템에서 사용할 수 있게 한다.^[1] 그러나 가상 머신은 종종 느리고 컴파일된 프로그램은 해당 가상 머신이 있는 컴퓨터에서만 실행할 수 있기 때문에 항상 이상적인 것은 아니다.^[2]

3. 캐나디안 크로스

캐나디안 크로스는 원래 머신보다 느리거나 불편한 머신용 크로스 컴파일러를 구축하는 기술이다. 세 대의 머신 A, B, C가 있을 때, 머신 A (예: IA-32 프로세서에서 윈도우 XP 실행)에서 머신 B (예: x86-64 프로세서에서 macOS 실행)에서 실행되는 크로스 컴파일러를 빌드하여 머신 C (예: ARM 프로세서에서 안드로이드 실행)용 실행 파일을 만든다.^[1]

이 경우, 머신 A는 느리지만 독점 컴파일러를 가지고 있고, 머신 B는 빠르지만 컴파일러가 없으며, 머신 C는 컴파일하기에 너무 느리다는 실질적인 이점이 있다.

GCC를 사용하는 경우, 다음과 같이 네 개의 컴파일러가 사용될 수 있다.^[1]

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

최종 크로스 컴파일러는 머신 A에서 실행될 수 없다. 대신 머신 B에서 실행되어 머신 C에서 실행될 실행 코드로 컴파일한다.

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

'캐나디안 크로스'라는 용어는 이러한 문제에 대한 논의가 진행되던 당시 캐나다에 세 개의 전국 정당이 있었기 때문에 붙여졌다.^[1]

4. GCC와 크로스 컴파일

GCC는 크로스 컴파일을 지원하는 자유 소프트웨어 컴파일러 모음이다. GCC는 여러 플랫폼과 언어를 지원한다.^[2]

GCC를 크로스 컴파일하려면 각 대상 플랫폼에 대해 binutils (특히 GNU 어셈블러)의 컴파일된 사본이 필요하다. 따라서 먼저 binutils를 `configure` 스크립트에 `--target=some-target` 스위치를 사용하여 컴파일해야 한다. GCC도 동일한 `--target` 옵션으로 `configure` 스크립트를 구성해야 한다. 그런 다음 경로에 binutils가 생성하는 도구가 있으면 GCC를 정상적으로 실행할 수 있다. (유닉스 계열 운영 체제(bash)에서):^[2]

```bash

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

```

GCC를 크로스 컴파일하려면 호스트 플랫폼에서 대상 플랫폼의 C 표준 라이브러리 일부를 사용할 수 있어야 한다. 전체 C 라이브러리를 컴파일할 수도 있지만, 이 방법은 신뢰성이 떨어질 수 있다. 다른 방법으로는 newlib를 사용하는 것이 있는데, 이는 C 소스 코드를 컴파일하는 데 필요한 가장 필수적인 구성 요소만 포함하는 작은 C 라이브러리이다.^[2]

GNU 오토툴 패키지 (autoconf, automake, libtool)는 ''빌드 플랫폼'', ''호스트 플랫폼'', ''대상 플랫폼'' 개념을 사용한다. ''빌드 플랫폼''은 컴파일러가 실제로 컴파일되는 곳이다. 대부분의 경우 빌드는 정의되지 않은 상태로 두어야 한다 (호스트에서 기본값으로 지정됨). ''호스트 플랫폼''은 컴파일러의 출력 (다른 컴파일러인지 여부와 관계없이)이 실행될 위치이다. ''대상 플랫폼''은 크로스 컴파일러를 크로스 컴파일할 때 사용되며, 패키지가 생성할 객체 코드 유형을 나타낸다. 그렇지 않으면 ''대상 플랫폼'' 설정은 관련이 없다.^[2] 예를 들어, 드림캐스트에서 실행될 비디오 게임을 크로스 컴파일한다고 가정해 보자. 게임이 컴파일되는 컴퓨터는 ''빌드 플랫폼''이고 드림캐스트는 ''호스트 플랫폼''이다. "호스트"와 "대상"이라는 이름은 사용 중인 컴파일러를 기준으로 하며 "아들"과 "손자"처럼 이동한다.^[3]

5. Manx Aztec C 크로스 컴파일러

뉴저지주 슈루즈버리에 위치한 Manx Software Systems는 1980년대부터 다양한 플랫폼용 C 컴파일러를 제작했다. Manx의 Aztec C는 MS-DOS, Apple II, Commodore 64, Mac 68k^[4] 및 Amiga 등 다양한 플랫폼에서 사용할 수 있었다.

1980년대부터 1990년대 Manx Software Systems가 사라질 때까지 Aztec C의 MS-DOS 버전^[5]은 네이티브 모드 컴파일러 또는 Commodore 64^[6] 및 Apple II^[7]용 크로스 컴파일러로 제공되었다.

Manx의 Aztec C86은 16비트 8086 계열 프로세서를 위한 레거시 운영 체제용 바이너리 실행 파일을 만들었다.

6. Microsoft C 크로스 컴파일러

Microsoft C 크로스 컴파일러는 1980년대 래티스 C를 기반으로 시작되었다.^[10]^[11] 1987년, MSC 5.1은 MS-DOS용 교차 언어 개발 환경을 제공하여 어셈블리 언어(MASM), QuickBASIC, 파스칼, 포트란 등 다양한 언어로 작성된 코드를 통합할 수 있게 했다.^[12] C 코드의 호출 규약은 매개변수를 스택에 역순으로 전달하고, 스택에 값을 반환하는 파스칼 호출 규약을 따랐으며, 이는 윈도우 및 OS/2 개발에 지속적으로 사용되었다.

1990년대 초, 마이크로소프트는 C 컴파일러를 윈도우, OS/2, GUI 프로그램 개발에 집중시켰다. ANSI C와 호환되는 MSC 6은 MS-DOS와의 혼합 언어 호환성을 유지하면서, 마이크로소프트 윈도우 3.0 및 3.1 API 작성에 사용되었다. 또한 32비트 어셈블리 지원 및 Windows for Workgroups, Windows NT 지원을 확장하여 Windows XP의 기반을 마련했다. thunk 기법을 통해 16비트 및 32비트 프로그램 간 통신을 가능하게 했다. MSC 7은 C++ 컴파일러로, MS-DOS 지원과 16/32비트 코드 생성을 모두 지원했다.

MSC 12는 마이크로소프트 비주얼 스튜디오 6과 함께 출시되었으며, 32비트 콘솔 애플리케이션을 지원하고, 윈도우 95, 윈도우 98, 윈도우 NT 코드 생성을 지원했다.^[1] MSC 13(비주얼 스튜디오 2003)과 MSC 14(비주얼 스튜디오 2005)는 모바일 시장과 ARM 아키텍처를 포함한 여러 플랫폼용 코드를 생성했다.^[2]

2001년, 마이크로소프트는 .NET Framework 컴파일러의 핵심인 공용 언어 런타임(CLR)을 개발하여, 윈도우 플랫폼에서 다양한 개발 언어를 혼합할 수 있게 했다.^[1] .NET 런타임과 CLR은 대상 컴퓨터의 프로세서 및 장치에 대한 매핑 계층을 제공하며, 비주얼 스튜디오의 C 컴파일러는 다양한 프로세서용 네이티브 코드를 컴파일할 수 있다.^[2] ARM 아키텍처용 .NET 애플리케이션은 다양한 프로세서가 있는 윈도우 머신에서 크로스 컴파일되며, 에뮬레이터 및 원격 배포 환경도 제공된다.^[3]

6. 1. 초기 역사 (1980년대)

마이크로소프트 C(MSC)는 1980년대부터 시작되었으며, 다른 컴파일러에 비해 역사가 짧다.^[10] 최초의 마이크로소프트 C 컴파일러는 래티스 C를 제작한 회사에서 만들었다.^[11] 1987년, MSC 5.1이 출시되면서 마이크로소프트는 MS-DOS용 교차 언어 개발 환경을 제공했다. 어셈블리 언어(MASM), QuickBASIC, 파스칼, 포트란을 포함한 마이크로소프트의 다른 언어로 작성된 16비트 바이너리 객체 코드는 "혼합 언어 프로그래밍"(현재는 "상호 언어 호출")이라는 프로세스를 통해 하나의 프로그램으로 연결될 수 있었다.^[12]

C 코드의 호출 규약은 매개변수를 스택에 "역순"으로 전달하고 값을 프로세서 레지스터가 아닌 스택에 반환하는 방식이었는데, 이 규칙은 윈도우 16비트 및 32비트 버전과 OS/2용 프로그램 개발에서 지속되었으며, 파스칼 호출 규약으로 알려져 있다.

당시 마이크로소프트 C가 사용된 또 다른 유형의 교차 컴파일은 Symbol Technologies PDT3100(재고 조사를 위해 사용)과 같은 휴대용 장치가 필요한 소매 애플리케이션에서 사용되었으며, 이는 8088 기반 바코드 리더를 대상으로 하는 링크 라이브러리를 제공했다.

6. 2. 1990년대 초반

1990년대 초반부터, 마이크로소프트는 자사의 C 컴파일러를 새롭게 부상하는 윈도우 시장, OS/2, GUI 프로그램 개발에 다시 집중했다. 최초의 ANSI C 호환 컴파일러였던 MSC 6을 통해서는 MS-DOS 측면에서도 혼합 언어 호환성이 유지되었지만, 마이크로소프트 윈도우 3.0 및 3.1의 API는 MSC 6으로 작성되었다. MSC 6은 또한 32비트 어셈블리 지원 및 Windows for Workgroups와 Windows NT의 지원을 제공하도록 확장되었으며, 이는 Windows XP의 기반을 형성하게 된다. thunk라고 불리는 프로그래밍 기법이 도입되어 런타임 바인딩(동적 연결)을 활용하는 16비트 및 32비트 프로그램 간의 통신을 가능하게 했다. 이는 모놀리식 16비트 MS-DOS 응용 프로그램에서 선호되었던 정적 바인딩과는 대조적이다.

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

6. 3. 1990년대 후반

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

비주얼 스튜디오 2003과 함께 출시된 MSC 13과 비주얼 스튜디오 2005와 함께 출시된 MSC 14는 윈도우 95와 같은 구형 시스템용 코드를 생성했지만, 모바일 시장과 ARM 아키텍처를 포함한 여러 대상 플랫폼용 코드를 생성했다.^[2]

6. 4. .NET 이후

2001년, 마이크로소프트는 공용 언어 런타임(CLR)을 개발했는데, 이는 비주얼 스튜디오 통합 개발 환경(IDE)에서 .NET Framework 컴파일러의 핵심을 이루었다. 응용 프로그래밍 인터페이스(API)에 있는 운영 체제의 이 계층은 윈도우 운영 체제를 실행하는 플랫폼에서 컴파일된 개발 언어를 혼합할 수 있게 해준다.^[1]

.NET Framework 런타임과 CLR은 대상 컴퓨터의 프로세서 및 장치에 대한 핵심 루틴에 대한 매핑 계층을 제공한다. 비주얼 스튜디오의 명령줄 C 컴파일러는 다양한 프로세서용 네이티브 코드를 컴파일하며 핵심 루틴 자체를 빌드하는 데 사용할 수 있다.^[2]

ARM 아키텍처 제품군에서 윈도우 모바일과 같은 대상 플랫폼용 마이크로소프트 .NET 애플리케이션은 다양한 프로세서가 있는 윈도우 머신에서 크로스 컴파일되며, 마이크로소프트는 과거의 크로스 컴파일러나 다른 플랫폼과 달리, 구성이 거의 필요 없는 에뮬레이터 및 원격 배포 환경도 제공한다.^[3]

7. 기타 크로스 컴파일러

Free Pascal은 처음부터 크로스 컴파일러로 개발되었다. 컴파일러 실행 파일(ppcXXX, 여기서 XXX는 대상 아키텍처)은 동일한 아키텍처의 모든 운영 체제에 대해 실행 파일(내부 링커가 없으면 객체 파일만, 내부 어셈블러가 없으면 어셈블리 파일만)을 생성할 수 있다.^[13] 다른 아키텍처로 컴파일하려면 먼저 컴파일러의 크로스 아키텍처 버전을 빌드해야 하며, 컴파일러 스위치(컴파일러 드라이버 fpc의 경우) -P 및 -T를 사용한다.^[13]

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

Plan 9(플랜 9)과 그 툴체인을 사용하는 이기종 시스템은 크로스 컴파일과 네이티브 컴파일을 구분하지 않으며, 메이크파일은 아키텍처에 독립적이다.

7. 1. Free Pascal

Free Pascal은 처음부터 크로스 컴파일러로 개발되었다. 컴파일러 실행 파일(ppcXXX, 여기서 XXX는 대상 아키텍처)은 동일한 아키텍처의 모든 운영 체제에 대해 실행 파일(내부 링커가 없으면 객체 파일만, 내부 어셈블러가 없으면 어셈블리 파일만)을 생성할 수 있다.^[13] 예를 들어, ppc386은 i386-linux, i386-win32, i386-go32v2(DOS) 및 기타 모든 운영 체제에 대해 실행 파일을 생성할 수 있다.^[13]

다른 아키텍처로 컴파일하려면 먼저 컴파일러의 크로스 아키텍처 버전을 빌드해야 한다. 결과 컴파일러 실행 파일은 이름에 대상 아키텍처 앞에 'cross'가 추가된다. 즉, 컴파일러가 x64를 대상으로 빌드되면 실행 파일은 ppcrossx64가 된다.

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

7. 2. Clang

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

7. 3. Plan 9

Plan 9(플랜 9)과 그 툴체인을 사용하는 이기종 시스템은 크로스 컴파일과 네이티브 컴파일을 구분하지 않는다. 메이크파일은 아키텍처에 독립적이다.

참조

_[1] 웹사이트 4.9 Canadian Crosses http://www.objsw.com[...] 2012-08-08
_[2] 웹사이트 Cross-Compilation (Automake) https://www.gnu.org/[...]
_[3] 웹사이트 Cross compilation https://mesonbuild.c[...]
_[4] 웹사이트 Obsolete Macintosh Computers http://docs.info.app[...] 2008-03-10
_[5] 웹사이트 Aztec C http://www.clipshop.[...]
_[6] 웹사이트 Commodore 64 http://www.clipshop.[...]
_[7] 웹사이트 Apple II http://www.clipshop.[...]
_[8] 웹사이트 MS-DOS Timeline http://members.fortu[...] 2008-05-01
_[9] 웹사이트 Inside Windows CE (search for Fenwick) https://www.amazon.c[...]
_[10] 웹사이트 Microsoft Language Utility Version History http://support.micro[...]
_[11] 웹사이트 History of PC based C-compilers http://www.itee.uq.e[...] 2007-12-15
_[12] 웹사이트 Which Basic Versions Can CALL C, FORTRAN, Pascal, MASM http://support.micro[...]
_[13] 웹사이트 Free Pascal Supported Platform List http://wiki.lazarus.[...] 2010-06-17
_[14] 서적 bit 単語帳共立出版 1990-08-15
_[15] 웹사이트 4.9 Canadian Crosses http://vmlinux.org/c[...] 2007-10-11

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com