## 0.1 호스트 운영체제(Host OS)와 타겟 하드웨어(Target Hardware) 간의 크로스 컴파일(Cross-Compilation) 패러다임

## 0.1 호스트 운영체제(Host OS)와 타겟 하드웨어(Target Hardware) 간의 크로스 컴파일(Cross-Compilation) 패러다임

리눅스 서버 프로그램이나 윈도우용 애플리케이션 개발 환경에 익숙한 소프트웨어 기술자라면, 컴파일된 바이너리가 그 자리(동일한 PC)에서 바로 실행(Native Compile)되는 개발 패턴에 젖어 있기 십상이다. 그러나 PX4-Autopilot과 같은 임베디드 펌웨어의 세계에 진입할 때 가장 먼저 맞닥뜨리는 이질적이고도 필수적인 장벽이 바로 크로스 컴파일(Cross-Compilation) 패러다임이다. 드론 제어기 구축을 시도하는 건축가라면 이 아키텍처의 당위성을 명확히 분별해야 한다.

본질적 불균형: 호스트(Host) PC와 타겟(Target) 보드의 차이

개발자가 앉아 있는 책상 위 **호스트 머신(Host OS)**은 고성능 인텔/AMD(x86_64) 또는 최신 애플 실리콘(ARM64) 명령어 셋과 수십 기가바이트의 거대한 RAM을 지닌 Ubuntu Linux 짐승이다.
반면, 비행기 뱃속으로 들어갈 **타겟 하드웨어(Target Board, 예: Pixhawk 6C)**는 단지 수 Mhz~수백 MHz로 박동하며 기껏해야 수백 킬로바이트(KB) 남짓한 RAM과 Flash 영역에서 죽을힘을 다해 버티는 저전력 ARM Cortex-M (ex. M4, M7) 아키텍처 영혼이다.

타겟 보드 스스로는 그 어마어마한 PX4 소스 코드를 읽어 들일 메모리 여유조차 없으며, G++ 컴파일러를 띄울 만한 운영체제도, 속도도 존재하지 않는다. 따라서 우리는 호스트 PC 체급의 거대한 뇌와 근육을 빌려, 타겟 보드만의 소형 뼈대(Instruction Set)에 꼭 들어맞는 나노급 기계어를 대신 조립해 주어야 한다. 이것이 크로스 컴파일이다.

툴체인 바이너리와 명령어 셋업의 단절

이러한 이중적 플랫폼 구조로 인해 개발 호스트 내에는 본질적으로 두 갈래의 컴파일러가 공존하게 된다.

  1. 네이티브 컴파일러 (Native Compiler, gcc/g++):
    SITL(Software In The Loop, 가상환경 드론 비행)이나 코드 내부 Python 생성기 스크립트 실행, 메타빌드 툴(CMake 자체) 구동 시 PC 자기 자신의 x86_64 리눅스 머신에서 돌리기 위한 컴파일러다.
  2. 크로스 컴파일러 (Cross Compiler, arm-none-eabi-gcc):
    오직 타겟 보드(Target)에 다운로드(Flashing)할 .px4 목적물 파일(.elf)을 찍어내기 위해, 타겟 보드의 명세서인 ARM 임베디드 코어의 명령어 파이프라인(Thumb-2 등)과 부동소수점 하드웨어 칩(FPU) 규격을 칼같이 맞춰가며 바이너리를 연산하는 외주 공구다.

만일 개발자가 툴체인(Toolchain) Path 설정을 까닥 잘못하여 크로스 컴파일 커맨드(make px4_fmu-vX)에 호스트 네이티브 컴파일러 리스트(g++)가 섞여 들어가거나, C-Library 포인터가 꼬이게 되면 호스트와 타겟 간의 호환성이 깨어지며 그 즉시 Architecture Mismatch 계열의 끔찍한 빌드 에러를 뿜어내는 원인이 된다. PX4 빌드 아키텍처를 이해한다는 것은 툴체인의 경로 환경 스크립트(ubuntu.sh 등)가 어떤 환경 변수에 arm-none-eabi- 접두어를 확실하게 꽂아 넣었는지 추적하는 능력과 직결된다.