📄 v1개정 이력 보기

  EC2→hb5u CUDA 바이너리 빌드 배포 설계 — glibc 비대칭과 CUDA 크로스 타겟팅 전략

    저자: EROS
    일자: 2026-07-08
    버전: v1
    분류: build · cross-compile · cuda · deployment · thesis-3d
    🏷️ build · glibc · cuda · deployment · cpp · thesis-3d(thesis-3d)
    상태: self-verified




  초록
  EC2(Amazon Linux 2023, glibc 2.34)에서 컴파일한 C++ CUDA 바이너리를 hb5u(Ubuntu 25.10, glibc 2.42)에 배포할 때의 호환성 문제를 분석한다. CPU ISA(x86_64)는 동일하므로 전통적 크로스 컴파일은 불필요하나, glibc 버전 비대칭과 CUDA 타겟 아키텍처(sm_120, Blackwell) 지정이 핵심 설계 과제다. glibc 하위 호환 원칙(낮은 버전 빌드 → 높은 버전 실행)을 활용하면 EC2 빌드 결과물이 hb5u에서 안전하게 실행된다.


EC2→hb5u CUDA 바이너리 빌드 배포 설계

— glibc 비대칭과 CUDA 크로스 타겟팅 전략 저자: EROS 일자: 2026-07-08 버전: v1 분류: build · cross-compile · cuda · deployment · thesis-3d

1. 환경 실측

EC2 (빌드 환경)

$ uname -m → x86_64 $ cat /etc/os-release → Amazon Linux 2023 $ ldd --version → GNU libc 2.34

hb5u (실행 환경)

$ uname -m → x86_64 $ cat /etc/os-release → Ubuntu 25.10 (Questing Quokka) $ ldd --version → Ubuntu GLIBC 2.42 $ nvidia-smi → RTX 5060 Laptop, compute 12.0, CUDA 13.2

항목 EC2 hb5u

CPU ISA x86_64 x86_64

OS Amazon Linux 2023 Ubuntu 25.10

glibc 2.34 2.42

GPU 없음 RTX 5060 (sm_120)

CUDA 드라이버 없음 595.71.05 / 13.2

1. 사령관 질문 분석 — "크로스 컴파일이 필요한가?" 2.1 CPU 아키텍처 관점 EC2와 hb5u 모두 x86_64. 이 경우 전통적 의미의 크로스 컴파일(예: x86→ARM)은 불필요하다. 같은 ISA이므로 EC2에서 생성된 기계어 명령어가 hb5u에서 그대로 실행된다. 2.2 CUDA 타겟 관점 — 이건 크로스 타겟팅 EC2: GPU 없음 → nvcc가 PTX/SASS 생성 불가 (GPU 없어도 컴파일은 가능) hb5u: RTX 5060 Laptop, compute capability 12.0 (Blackwell)

nvcc -arch=sm_120을 EC2에서 실행하면 GPU 없이도 hb5u GPU에서 실행될 Blackwell SASS 코드를 생성할 수 있다. 이것이 CUDA 크로스 타겟팅이다. CPU 크로스 컴파일과 개념적으로 동일하지만, 컴파일러(nvcc)가 기본적으로 지원한다. 2.3 glibc 버전 관점 — 핵심 비대칭 이것이 실제 설계에서 가장 중요한 차이점이다. 빌드(EC2): glibc 2.34 실행(hb5u): glibc 2.42

glibc 하위 호환 원칙: glibc는 하위 호환성을 보장한다. 즉: - glibc 2.34에서 빌드 → glibc 2.34 이상 환경에서 실행 가능 ✅ - glibc 2.42에서 빌드 → glibc 2.42 미만 환경에서 실행 불가 ❌ 따라서 낮은 버전(EC2 2.34) 빌드 → 높은 버전(hb5u 2.42) 실행 = 안전. 반대 방향(hb5u에서 빌드 → EC2로 배포)은 불가: hb5u 빌드 바이너리가 glibc 2.42 심볼 참조 EC2 glibc 2.34에서 로드 시 → symbol lookup error

1. 빌드 전략 — EC2에서 빌드, hb5u로 배포 3.1 의존성 설계 layout_engine 바이너리 ├─ libcuda.so.1 [동적] hb5u 드라이버에 존재 → 배포 불필요 ├─ libcudart.so [정적 링크] -cudart static → 바이너리에 포함 ├─ libstdc++.so [정적 링크] -static-libstdc++ → 바이너리에 포함 ├─ libgcc_s.so [정적 링크] -static-libgcc → 바이너리에 포함 └─ libc.so (glibc) [동적, 불가피] → EC2 2.34 빌드로 호환성 확보

glibc는 완전 정적 링크가 사실상 불가능하다 (DNS 리졸버 등 동적 로드 구조). 대신 낮은 버전(EC2 2.34)에서 빌드해 호환성을 확보한다. 3.2 빌드 명령

EC2에서 실행 (nvcc 설치 후)

nvcc -O3 \ -arch=sm_120 \ -cudart static \ -Xcompiler "-O3 -static-libgcc -static-libstdc++" \ layout_engine.cu -o layout_engine

의존성 검증

ldd layout_engine

기대 출력:

linux-vdso.so.1

libcuda.so.1 => /lib/x86_64-linux-gnu/libcuda.so.1

libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

→ libcudart, libstdc++, libgcc 없음 (정적 링크됨)

hb5u 배포

scp layout_engine hb5u:/home/moos/dev_ws/dual_arms/scripts/

3.3 -arch=sm_120 지원 nvcc 버전 sm_120 (Blackwell)은 CUDA 12.8+에서 지원된다. EC2에 설치할 nvcc 버전이 12.8 이상이어야 한다.

EC2에서 확인

nvcc --list-gpu-arch | grep sm_120

없으면 cuda-toolkit 버전 업그레이드 필요

1. 대안 전략 비교

전략 설명 장점 단점

A. EC2 빌드 → hb5u 배포 (권장) EC2에 nvcc 설치, 바이너리 scp sudo 불필요(hb5u), glibc 순방향 호환 EC2에 nvcc 설치 필요

B. hb5u 직접 빌드 hb5u에 cuda-toolkit 설치 환경 완전 일치 sudo 필요, 설치 후 삭제 가능

C. Docker 동일 환경 빌드 EC2에서 Ubuntu 25.10 컨테이너 완전 환경 일치 Docker 설치 필요, 복잡

D. GitHub Actions CI push 시 자동 빌드·배포 자동화 설정 복잡, 초기 투자 큼

전략 A 선택 근거: glibc 하위 호환 원칙으로 호환성 보장됨. hb5u sudo 문제 우회 가능. EC2는 이미 제어권이 있음.

1. glibc 심볼 버전 검증 방법 빌드 후 의도치 않게 높은 glibc 심볼이 참조되지 않았는지 확인:

바이너리가 요구하는 최소 glibc 버전 확인

objdump -p layout_engine | grep GLIBC

예: GLIBC_2.17, GLIBC_2.34 등

→ 2.34 이하 심볼만 있으면 hb5u(2.42)에서 실행 보장

1. 빌드 파이프라인 설계 [EC2] ~/hypercode/services/layout-engine/ ├─ layout_engine.cu # CUDA 소스 ├─ Makefile # 빌드 자동화 └─ deploy.sh # scp → hb5u + viz_server 재시작

[Makefile] build: nvcc -O3 -arch=sm_120 -cudart static \ -Xcompiler "-O3 -static-libgcc -static-libstdc++" \ layout_engine.cu -o layout_engine objdump -p layout_engine | grep GLIBC # 심볼 검증

deploy: build scp layout_engine hb5u:/home/moos/dev_ws/dual_arms/scripts/ ssh hb5u 'kill $(pgrep -f viz_server.py); bash /tmp/start_viz.sh'

[deploy.sh]

!/bin/bash

make deploy

1. 결론 사령관의 직관이 정확했다. EC2와 hb5u는 CPU ISA는 동일하지만 glibc 버전(2.34 vs 2.42)이 다르다. 그러나 이는 전통적 크로스 컴파일 문제가 아니라 glibc 하위 호환 방향 문제다. 해결 원칙:
2. 항상 낮은 glibc 환경(EC2)에서 빌드 → 높은 환경(hb5u)에서 실행 보장
3. CUDA 크로스 타겟팅: -arch=sm_120으로 EC2에서 hb5u GPU용 코드 생성
4. 정적 링크 최대화: cudart, libstdc++, libgcc 정적 링크 → libcuda.so.1 하나만 동적
5. objdump로 심볼 검증: 빌드 후 최소 glibc 버전 확인 자동화 다음 단계: EC2에 nvcc(CUDA 12.8+) 설치 후 layout_engine.cu 구현 및 배포.