11.11.3.2 RMW 플러그인(rmw_zenoh)의 OS 종속적 빌드 시스템 및 브랜치 일치 기법

11.11.3.2 RMW 플러그인(rmw_zenoh)의 OS 종속적 빌드 시스템 및 브랜치 일치 기법

ROS2의 신경망 생태계에서 퍼블리셔(Publisher)와 서브스크라이버(Subscriber)의 통신이 기본 DDS(FastDDS, CycloneDDS 등)를 거치지 않고 직접 Zenoh 프로토콜의 대동맥 위로 탑승하기 위해서는, ROS2 통신 추상화 레이어 아래에 위치한 미들웨어 로컬 플러그인, 즉 rmw_zenoh 의 삽입이 필수적이다.

문제는 이 플러그인의 이식이 극도로 예민한 거부반응을 수반한다는 점이다. 개발자 워크스테이션(Ubuntu x86)에서는 우아하게 빌드되던 패키지가, Yocto 리눅스를 커스텀 빌드한 Jetson 보드나 Raspberry Pi 같은 임베디드 ARM 단말에 타게팅되는 순간 수만 줄에 달하는 CMake 링킹 에러(Linking Error)를 쏟아내며 개발팀을 공황에 빠뜨린다. 본 절에서는 ROS2 배포판의 브랜치와 빌드 시스템의 OS 종속성을 굴복시키는 교차 검증 런북을 설파한다.

1. ROS-Distro와 플러그인 브랜치의 심각한 불협화음

ROS2 시스템은 Ubuntu 배포판 위기를 아슬아슬하게 넘나든다. Foxy 배포판(Ubuntu 20.04)을 사용하는 구형 로봇 단말 시스템에서, 깃허브(GitHub)의 rmw_zenoh 리포지토리를 main 브랜치나 최신 릴리즈로 강제 짐풀기(Git clone)하여 빌드(colcon build)하는 행위는 ROS 생태계에 대한 폭력이나 진배없다.

ROS2의 미들웨어 문법(RMW Interface)은 메이저 버전이 올라갈 때마다 함수의 포인터 인자나 할당자(Allocator) 파라미터 갯수를 무자비하게 날려버린다(Breaking Changes). 최신 rmw_zenoh_cpp 메인 브랜치는 Humble 또는 Rolling 버전의 문법을 타겟으로 설계되어 있으므로, Foxy C++ 컴파일러가 이를 소화하려고 들면 포인터 인터페이스 자체가 부서지는 치명적인 런타임 붕괴에 직면한다.

[아키텍처 강제 조약]:
개발자는 rmw_zenoh 소스 코드를 호스트 공간으로 다운로드한 직후, 어떠한 행동보다 앞서 로컬 ROS2 배포판 명칭(Distro Name)과 완벽하게 스펠링 하나 틀리지 않고 일치하는 깃 브랜치(Git Branch)로 체크아웃(Checkout)할 것을 서약해야 한다.

# Ubuntu 22.04 + ROS2 Humble 사용자의 의무적 절차 모형
git clone https://github.com/ros2/rmw_zenoh.git src/rmw_zenoh
cd src/rmw_zenoh

# [필수 런북] 로봇에 설치된 ROS 배포판 환경 변수 기반 강제 체크아웃
git checkout humble

2. CMakeLists 종속성과 Rust 링커(Rustc/Cargo) 생태계 충돌 제어

rmw_zenoh 빌드를 지옥으로 끌고 가는 또 다른 복병은 빌드 메커니즘의 “혼종성(Hybridization)“이다.
ROS2의 상위 빌더인 colcon 및 CMake가 C++ 구역을 통제하지만, 그 아래 심부 코어 라이브러리는 Rust 엔진(cargo)을 타고 컴파일된다.

즉 C++ 링커가 구동 중인 임베디드 리눅스의 glibc 버전과, 내부에서 펌프질을 하는 Rust 컴파일러 툴체인(rustup)의 타깃 아키텍처(예: aarch64-unknown-linux-gnu)가 톱니바퀴처럼 물리쳐 맞물리지 않으면 빌드는 결코 100%에 도달하지 않는다.
임베디드 타겟 장비에서 컴파일 에러가 터졌을 때 가장 먼저 검안(Inspect)해야 할 것은 C++ 의존성이 아니라 Rust 엔진의 버전 부합성이다.

# OS 빌드 환경 불일치 진단 프로토콜
rustc --version
# 결과가 빌드 타겟과 불일치하거나 너무 오래된 버전(예: 1.58)이라면 
# ROS2 C++ 20 문법과 융합되는 1.70 이상으로 강제 격상하라!
rustup update stable
cargo clean

플러그인의 클린 빌드를 돌리기 전 colcon 스크립트를 맹신하지 말고, CMake 환경이 호스트의 rustc 패스(Path)를 제대로 물고 있는지 인프라 레벨의 연성 조사를 수행하라.

3. ABI(Application Binary Interface) 무결성과 V-Table 결손 포착

빌드 커맨드가 Finished로 끝났다고 환호하기엔 이르다. OS 환경이 난해하게 섞인 시스템에서는 동적 라이브러리(.so)가 컴파일되었더라도 런타임에 심볼(Symbol)을 찾지못하는 병증, 이른바 V-Table 결손(Undefined Symbol) 이 튀어나온다.
이는 C++ 코어와 Rust FFI 간의 호출 규약(ABI)이나 libstdc++ 라이브러리의 파편화로 인해, 함수 선언의 이름 규격(Name Mangling)이 엉뚱하게 박혀버렸음을 뜻한다.

로봇에 플러그인을 최종 탑재(RMW_IMPLEMENTATION=rmw_zenoh_cpp ros2 run ...)하기 전, 타겟 OS 상에서 nm 이나 ldd 리눅스 명령어를 발동하여 컴파일된 librmw_zenoh_cpp.so 라이브러리가 호스트 시스템의 커널 로더(ld-linux)와 완벽히 결박(Bind)되어 미아(Orphan) 포인터를 발생시키지 않는지 색출하는 것이 노련한 시스템 소프트웨어 아키텍트의 수성 자질이다.