리눅스에서 크로스 컴파일이란 한 플랫폼에서 다른 플랫폼에서 실행 가능한 코드를 생성하는 것을 의미합니다. 즉, 소스 코드를 컴파일하는 플랫폼과 소스 코드의 컴파일된 프로그램을 실행하는 플랫폼은 서로 다른 플랫폼입니다. 크로스 컴파일을 사용하는 이유: 1. 대상 시스템에는 기본적으로 컴파일할 수 있는 기능이 없습니다. 2. 소스 코드를 컴파일할 수 있는 플랫폼이 대상 플랫폼과 다릅니다.
이 튜토리얼의 운영 환경: linux5.9.8 시스템, Dell G3 컴퓨터.
크로스 컴파일
소위 "Cross_Compile"이란 소스 코드를 컴파일하는 플랫폼과 소스 코드의 컴파일된 프로그램을 실행하는 플랫폼이 서로 다른 두 플랫폼을 의미합니다. 예를 들어 Intel x86 아키텍처/Linux(Ubuntu) 플랫폼에서 크로스 컴파일 도구 체인을 사용하여 생성된 실행 파일은 ARM 아키텍처/Linux에서 실행됩니다.
간단히 말하면 한 플랫폼에서 다른 플랫폼에서 실행 가능한 코드를 생성하는 것입니다. 동일한 아키텍처가 다른 운영 체제를 실행할 수 있는 것처럼, 동일한 운영 체제가 다른 아키텍처에서도 실행될 수 있습니다.
크로스 컴파일은 상대적으로 복잡하며 다음 문제를 고려해야 합니다.
CPU 아키텍처: ARM, x86, MIPS 등
바이트 순서: 빅엔디안 및 리틀엔디안;
부동 소수점 숫자 지원
애플리케이션 바이너리 인터페이스(ABI)
크로스 컴파일을 사용하는 이유 두 가지 주된 이유가 있습니다:
크로스 컴파일을 위한 대상 시스템은 일반적으로 메모리가 적고 디스플레이 장비가 열악하거나 아예 없으며 로컬에서 컴파일할 수 있는 기능이 없습니다. 소스 코드를 컴파일하려면 CPU 아키텍처나 운영 체제가 대상 플랫폼과 다릅니다.
크로스 컴파일 툴 체인은 크로스 컴파일을 위한 필수 도구이자 임베디드 개발자가 능숙하게 마스터해야 하는 기술입니다.
크로스 컴파일이 왜 어려운가요?
이식 가능한 네이티브 컴파일은 어렵습니다.
대부분의 프로그램은 x86 하드웨어에서 개발되고 기본적으로 컴파일됩니다. 크로스 컴파일에는 두 가지 유형의 문제, 즉 프로그램 자체 문제와 빌드 시스템 문제가 발생할 수 있습니다.첫 번째 문제 범주는 네이티브 및 크로스 빌드를 포함하여 x86이 아닌 모든 대상에 영향을 미칩니다. 대부분의 프로그램은 관련 플랫폼과 일치해야 하는 실행 중인 시스템 유형에 대해 가정합니다. 그렇지 않으면 프로그램이 실행되지 않습니다. 일반적인 가정은 다음과 같습니다.
Word 크기 - int에 포인터를 복사하면 64비트 플랫폼에서 데이터가 손실될 수 있으므로 sizeof(long) 대신 4를 곱하여 malloc 크기를 결정하는 것은 좋지 않습니다. 정수 오버플로는 x=1000일 때 "if (x+y
Endianness - 서로 다른 시스템은 바이너리 데이터를 내부적으로 서로 다른 방식으로 저장하며, 디스크나 네트워크에서 int 또는 float 데이터를 읽으면 변환이 필요할 수 있습니다.
정렬 - 일부 플랫폼(예: arm)은 4바이트의 배수인 주소에서만 정수를 읽거나 쓸 수 있습니다. 그렇지 않으면 세그폴트가 발생합니다. 정렬된 데이터와 정렬되지 않은 데이터의 처리 속도가 느려지고 컴파일러는 일반적으로 구조 정렬 변수를 채웁니다. 구조를 디스크나 네트워크를 통해 전송할 수 있는 데이터 블록으로 처리하려면 일관된 표현을 보장하기 위한 추가 작업이 필요합니다.
기본 서명 - 기본적으로 서명되거나 서명되지 않은 "char" 데이터 유형은 플랫폼마다(컴파일러에서 컴파일러까지) 다양하므로 매우 놀라운 버그가 발생합니다. 간단한 해결 방법은 기본값을 알려진 값으로 강제하는 "-funsigned-char"와 같은 컴파일러 매개변수를 제공하는 것입니다.
NOMMU - 대상 플랫폼에 메모리 관리 장치가 없는 경우 몇 가지 사항을 변경해야 합니다. fork()가 아닌 vfork()가 필요하며 특정 유형의 mmap() 작업만 필요합니다(공유 또는 읽기 전용, 쓰기 중 복사는 아님). 스택은 동적으로 커지지 않습니다.
대부분의 패키지는 네이티브 컴파일 시 이식성을 목표로 하며 최소한 적절한 개발 메일링 리스트에 제출된 위의 문제를 수정하는 패치를 허용합니다(NOMMU 문제 제외).
크로스 컴파일에는 고유한 문제 세트가 있습니다.
구성 문제 - 별도의 구성 단계가 있는 패키지(표준 구성/make/make 설치의 "./configure" 섹션) )은 일반적으로 바이트 순서나 페이지 크기 등을 테스트하며 기본적으로 컴파일할 때 이식 가능합니다. 크로스 컴파일을 하게 되면 호스트 시스템과 타겟 시스템에서 이러한 값이 다르며, 호스트 시스템에서 테스트를 실행하면 잘못된 답이 나옵니다. 대상에 소프트웨어 패키지가 없거나 버전이 호환되지 않는 경우 구성은 호스트에 소프트웨어 패키지 지원이 있는지 여부를 감지합니다.
HOSTCC 대 TARGETCC - 빌드 프로세스에는 위에 구성된 테스트와 같이 호스트 시스템에서 실행하기 위한 컴파일 또는 코드를 생성하는 프로그램(예: .h 파일을 생성하는 C 프로그램, 기본 빌드 중에 #include)이 필요합니다. . 호스트 컴파일러를 대상 컴파일러로 교체하여 빌드 프로세스 중에 런타임 라이브러리를 중단합니다. 이러한 라이브러리는 호스트 및 대상 컴파일러에 대한 액세스가 필요하며 사용 시기를 지정해야 합니다.
도구 체인 누출 - 부적절하게 구성된 크로스 컴파일 도구 체인은 호스트 시스템의 일부 내용을 컴파일된 프로그램으로 누출하여 감지하기 쉽지만 진단 및 수정이 어려운 오류를 유발합니다. 툴체인은 잘못된 헤더 파일을 #include하거나 링크할 때 잘못된 라이브러리 경로를 검색할 수 있습니다. 공유 라이브러리는 종종 다른 공유 라이브러리에 의존하므로 잠재적으로 호스트 시스템에 대한 예기치 않은 링크 타임 참조가 몰래 들어옵니다.
라이브러리 - 동적으로 링크된 프로그램은 컴파일 타임에 적절한 공유 라이브러리에 액세스해야 합니다. 프로그램이 링크할 수 있도록 대상 시스템의 공유 라이브러리를 크로스 컴파일 도구 체인에 추가해야 합니다.
테스트 - 네이티브 빌드에서 개발 시스템은 편리한 테스트 환경을 제공합니다. 크로스 컴파일 시 "hello world" 빌드가 성공했는지 확인하려면 (적어도) 부트로더, 커널, 루트 파일 시스템 및 공유 라이브러리를 구성해야 할 수 있습니다.
각주 1: 컴퓨터 유형 간의 가장 중요한 차이점은 프로그램을 실행하는 프로세서입니다. 다른 차이점으로는 라이브러리 ABI(예: glibc 및 uClibc), 구성 가능한 엔디안이 있는 시스템(armeb가 있는 arm), 또는 32비트 및 64비트 코드(예: x86의 x86-64)를 실행할 수 있는 다른 시스템 모드입니다.
각주 2: 컴파일러를 빌드할 때 세 번째 유형은 호스트 시스템에서 실행되지 않는 크로스 컴파일러인 "캐나디안 크로스"라고 합니다. Canadian Cross-Build 하나의 대상 플랫폼에서 실행되고 다른 대상 시스템에서 코드를 생성하는 컴파일러입니다. 먼저 호스트에서 첫 번째 대상까지 임시 크로스 컴파일러를 만들고 두 번째 대상으로 다른 크로스 컴파일러를 빌드하여 이러한 외부 컴파일러를 빌드합니다. 첫 번째 크로스 컴파일러의 대상은 새 컴파일러가 실행될 호스트 컴퓨터가 되고, 두 번째 대상은 새 컴파일러가 출력을 생성할 플랫폼이 됩니다. 이 기술은 대상 플랫폼에 대한 새로운 기본 컴파일러를 크로스 컴파일하는 데 자주 사용됩니다.
각주 3: 최신 데스크톱 시스템은 에뮬레이터에서 기본적으로 컴파일된 대상을 에뮬레이트하는 것이 실제로 실행 가능한 전략일 만큼 충분히 빠릅니다. 크로스 컴파일보다 훨씬 느리고 대상에 대한 기본 빌드 환경을 찾거나 생성해야 하며(어차피 크로스 컴파일러를 설정해야 함) 배포할 에뮬레이터와 실제 하드웨어 간의 차이로 인해 충돌이 발생할 수 있습니다.
각주 4: 크로스 컴파일 툴체인은 "armv5l-linux-gcc"라는 유틸리티 이름 앞에 접두사를 붙이는 경향이 있습니다. 단순히 "gcc"라고 하면 호스트 컴파일러와 네이티브 컴파일러가 동시에 $PATH에 있을 수 없습니다.
관련 추천: "Linux 비디오 튜토리얼"
위 내용은 리눅스 크로스 컴파일이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!