이 페이지에서

임베디드 리눅스 장치 구성

특정 장치를 위한 Qt 크로스 컴파일에는 툴체인과 sysroot가 필요합니다. 툴체인에는 gcc 또는 다른 컴파일러의 버전과 크로스 컴파일을 위해 빌드된 관련 도구들이 포함되어 있어야 합니다. 즉, 이러한 도구들은 호스트 시스템(일반적으로 x64)에서 실행되면서 대상 아키텍처(예: 32비트 또는 64비트 ARM)용 바이너리를 생성합니다. sysroot에는 대상 시스템용 헤더와 라이브러리가 포함되어 있어, 호스트에서 라이브러리와 애플리케이션을 컴파일하고 링크할 수 있게 해줍니다.

이 개요 페이지에서는 Yocto나 Buildroot와 같은 배포판 빌드 시스템을 사용하지 않는 일반적인 접근 방식을 설명합니다. 적절한 툴체인과 sysroot만 있다면 언제든지 크로스 컴파일을 통해 Qt를 기기에 배포할 수 있습니다.

경고: 이 페이지는 일반적이고 개괄적인 내용만을 제공합니다. 빌드 환경, 대상 장치 및 툴체인에 따라 달라질 수 있는 세부 사항이 매우 많습니다. 확실하지 않은 경우 시스템 통합 업체에 문의하십시오. 미리 빌드된 참조 이미지 및 SDK에 대해서는 Boot to Qt 제공 항목을 참조하십시오.

X11이나 Wayland와 같은 윈도우 시스템 없이 Qt 기반 애플리케이션을 실행할 경우, 일부 기기에서는 EGL 및 OpenGL ES 지원을 위해 벤더별 조정 코드가 필요합니다. 이는 EGLFS 플랫폼 플러그인의 백엔드 형태로 제공됩니다. 이는 소프트웨어 기반 렌더링 전용인 LinuxFB 플랫폼 플러그인을 사용하는 플랫폼과 같이 가속 기능이 없는 플랫폼에는 해당되지 않습니다. Qt 6 기준, 많은 임베디드 시스템은 drm을 사용하여 비디오 모드를 설정하고, 디스플레이 커넥터 및 그래픽 서페이스를 관리합니다. 예를 들어, NXP i.MX8 기반 장치나 Raspberry Pi 4는 이 방식을 사용하므로, EGLFS에 가장 일반적으로 사용되는 백엔드는 eglfs_kms입니다. 이 백엔드는 drm 를 통해 EGL 및 OpenGL ES 기반 렌더링을 지원하며, 서피스 및 버퍼 관리에는 gbm 를 사용합니다. NXP 의 i.MX6와 같은 구형 장치는 eglfs_viv 와 같은 전용 eglfs 백엔드를 사용하여 EGL 창 표면을 프레임버퍼에 연결하는, GPU 벤더별 레거시 방식을 계속 사용할 것입니다.

참고: Qt는 임베디드 장치의 소프트웨어 스택에서 단지 하나의 구성 요소일 뿐이라는 점을유의하십시오 . 특히 가속 그래픽이 관련된 경우, Qt는 디스플레이 드라이버와 같은 사용자 공간 및 커널 구성 요소에 대한 적절한 구성이 적용된, 정상적으로 작동하는 그래픽 스택을 필요로 합니다. 이러한 구성 요소들은 Qt의 관할 범위를 벗어나며, 가속 그래픽을 포함하여 기본 시스템이 완벽하게 작동하고 최적의 상태를 유지하도록 보장하는 것은 시스템 통합업체의 책임입니다.

임베디드 리눅스 시스템의 그래픽 및 입력 구성에 대한 자세한 내용은 Qt for Embedded Linux를 참조하십시오.

툴체인 파일과 장치 Makespecs의 차이

Qt 5에서는 일반적으로 qtbase/mkspecs/devices 디렉터리 아래의 장치 사양(device spec)을 사용합니다. 여기에는 특정 장치에 적합한 컴파일러 및 링커 플래그가 포함되어 있으며, sysroot 내 비표준 위치에 있는 경우 올바른 EGL 및 OpenGL ES 라이브러리가 선택되도록 보장합니다.

예를 들어, 다음과 같은 configure 명령어를 사용하여 Raspberry Pi 2용 Qt 5 빌드를 구성할 수 있습니다.

./configure -release -opengl es2 -device linux-rasp-pi2-g++ -device-option CROSS_COMPILE=$TOOLCHAIN/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- -sysroot $ROOTFS -prefix /usr/local/qt5

참고: ` ninja ` 실행 파일이 있는 경우,`configure `는 항상 Ninja 생성기 및 빌드 도구를 사용합니다. Ninja는 크로스 플랫폼이며, 기능이 풍부하고 성능이 뛰어나 모든 플랫폼에서 권장됩니다. 다른 생성기를 사용하는 것도 가능할 수 있지만, 공식적으로 지원되지는 않습니다.

Qt 6 및 CMake의 경우, 이 접근 방식만으로는 더 이상 충분하지 않습니다. 대신, configure를 실행하기 전에 CMake 툴체인 파일을 제공해야 합니다. 이 파일에서 컴파일러 및 링커 플래그에 대한 사용자 정의와 툴체인 및 sysroot 특유의 특이 사항에 대한 처리가 이루어집니다.

다음 섹션에서는 최소한의 사용자 정의만으로 다양한 경우에 사용할 수 있는 툴체인 파일을 소개하겠습니다. 이 파일은 본 블로그 게시물에서 제시한 접근 방식을 기반으로 합니다.

참고: 아래에 제시된 툴체인파일은 예시일 뿐이며, 특정 기기에 따라 추가적인 사용자 정의가 필요한 경우가 많습니다. 사용자와 시스템 통합업체는 원하는 방식으로 자유롭게 자체 툴체인 파일을 생성할 수도 있습니다.

Qt 자체를 빌드하는 데는 CMake만이 지원되는 빌드 시스템이지만, Qt 6.0에서는 여전히 qmake 를 사용하여 애플리케이션을 빌드할 수 있습니다. 크로스 컴파일과 호환되는 qmake 설정을 얻으려면, CMake나 configure에 일부 레거시 인수를 지정해야 합니다.

호스트 도구

Qt를 크로스 컴파일하려면 호스트용 Qt 빌드가 준비되어 있어야 합니다. 자세한 내용은 Qt 크로스 컴파일을 참조하십시오.

Qt 구성

다음 요소들이 준비되어 있다고 가정해 봅시다:

  • $HOME/rpi-sdk 경로의 툴체인 및 sysroot,
  • $HOME/qt-cross 경로에 최소한 qtbase 모듈이 포함된 Qt 체크아웃,
  • $HOME/qt-host 에 호스트용 Qt 빌드가 존재한다고 가정합니다.

또한, 구성을 시작하기 전에 다음 사항을 결정해야 합니다:

  • 빌드가 완료되면 Qt 빌드 결과물을 로컬 시스템의 어디에 설치할 것인가? 이 예제에서는 $HOME/qt6-rpi 을 사용할 것입니다.
  • Qt 빌드는 디바이스의 어디에 배포될 것인가? 이 예제에서는 /usr/local/qt6 를 사용할 것입니다.

이 예제에서는 Yocto를 통해 생성된 Raspberry Pi 4 SDK(툴체인+sysroot)를 사용할 예정이지만, 여기서의 지침은 Yocto에 전혀 의존하지 않는 완전히 일반적인 내용입니다. 올바른 크로스 컴파일러 및 기타 경로로 툴체인 파일을 업데이트하기만 하면, 다른 툴체인과 sysroot를 사용할 때도 단계는 동일합니다.

build 디렉터리를 생성하고 해당 디렉터리로 이동한 후:

$HOME/qt-cross/qtbase/configure -release -opengl es2 -nomake examples -nomake tests \
  -qt-host-path $HOME/qt-host                              \
  -extprefix $HOME/qt6-rpi                                 \
  -prefix /usr/local/qt6                                   \
  -- -DCMAKE_TOOLCHAIN_FILE=$HOME/qt-cross/toolchain.cmake

실제로 이 configure 명령어는 다음과 같은 직접적인 CMake 호출과 동일합니다:

cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DINPUT_opengl=es2 -DQT_BUILD_EXAMPLES=OFF -DQT_BUILD_TESTS=OFF \
  -DQT_HOST_PATH=$HOME/qt-host                           \
  -DCMAKE_STAGING_PREFIX=$HOME/qt6-rpi                   \
  -DCMAKE_INSTALL_PREFIX=/usr/local/qt6                  \
  -DCMAKE_TOOLCHAIN_FILE=$HOME/qt-cross/toolchain.cmake  \
  $HOME/qt-cross/qtbase

적절한 툴체인 파일이 주어지면, 이것만으로도 Qt 빌드를 생성할 수 있으며, 이를 통해 CMake를 사용하여 애플리케이션을 빌드할 수 있습니다. qmake 를 사용하여 애플리케이션도 빌드할 수 있도록 하려면, 위에 표시된 모든 인자 외에도 Qt 5 스타일의 디바이스 사양과 디바이스 옵션을 지정해야 합니다:

$HOME/qt-cross/qtbase/configure ...
  ...
  -device linux-rasp-pi4-v3d-g++ \
  -device-option CROSS_COMPILE=$HOME/rpi_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
  -device-option DISTRO_OPTS="hard-float" \
  ...

기본적으로 크로스 컴파일 시에는 대상 장치에서 실행될 예정인 Qt 라이브러리와 도구만 빌드됩니다. moc 및 uic 와 같은 빌드 관련 도구는 빌드되지 않습니다. 이러한 도구의 빌드를 활성화하려면 QT_FORCE_BUILD_TOOLS 를 ON 로 설정하면 됩니다.

참고: QT_FORCE_BUILD_TOOLS 가활성화되면 qmake 와 같은 도구의 대상 바이너리가 스테이징 위치에 설치됩니다. 따라서 qmake 를 사용하여 애플리케이션을 빌드하는 경우, 대신 host-qmake 스크립트를 호출하십시오.

오류 없이 구성이 완료되면 cmake --build . --parallel 를 실행하여 빌드하십시오. 빌드가 완료되면 cmake --install . 를 실행하여 결과물을 $HOME/qt6-rpi 에 설치하십시오. 이후 rsync, scp 또는 다른 방법을 사용하여 Qt 빌드를 기기에 배포할 수 있습니다.

개별 Qt 모듈을 빌드하는 경우, 스테이징 위치(예:$HOME/qt6-rpi )의 bin 디렉터리에 있는 qt-configure-module 스크립트를 사용하여 qtdeclarative, qtquick3d 등과 같은 추가 모듈을 구성할 수 있습니다. 그런 다음 cmake --build . 을 사용하여 빌드하고, 다음 명령을 실행하여 스테이징 위치에 설치할 수 있습니다. cmake --install .

참고: 빌드를 시작하기전에 항상 구성 단계의 출력을 주의 깊게 확인하십시오. 예상되는 모든 기능이 활성화되어 있습니까? 구성 단계에서 필수 기능이 활성화되지 않은 상태에서 빌드를 수행하고 기기에 배포하는 것은 무의미합니다.

예를 들어, OpenGL을 통한 그래픽 가속을 원할 경우 다음 기능에 각별히 주의를 기울여야 합니다:

EGL .................................... yes
OpenGL:
  Desktop OpenGL ....................... no
  OpenGL ES 2.0 ........................ yes
  OpenGL ES 3.0 ........................ yes
...
evdev .................................. yes
libinput ............................... yes
...
EGLFS .................................. yes
EGLFS details:
  EGLFS OpenWFD ........................ no
  EGLFS i.Mx6 .......................... no
  EGLFS i.Mx6 Wayland .................. no
  EGLFS RCAR ........................... no
  EGLFS EGLDevice ...................... yes
  EGLFS GBM ............................ yes
  EGLFS VSP2 ........................... no
  EGLFS Mali ........................... no
  EGLFS Raspberry Pi ................... no
  EGLFS X11 ............................ no
LinuxFB ................................ yes

라즈베리 파이 4 예제의 경우, EGL, OpenGL ES 및 EGLFS GBM 가 모두 yes 로 보고되어야 합니다. 그렇지 않으면 EGLFS 플랫폼 플러그인과 그 eglfs_kms 백엔드가 기기에서 작동하지 않습니다. 마우스, 키보드 및 터치 입력을 정상적으로 사용하려면 evdev 또는 libinput 중 하나를 활성화해야 합니다.

마찬가지로, X11을 해당 장치의 윈도우 시스템(또는 그 중 하나)으로 사용할 계획이라면, xcb 및 X11 관련 기능이 yes 로 표시되어 있는지 확인해야 합니다.

툴체인 파일 예시

$HOME/rpi-sdk 하위에 sysroot와 툴체인이 준비되어 있다고 가정합니다. TARGET_SYSROOT 및 CROSS_COMPILER 는 사용 중인 툴체인과 sysroot에 맞게 조정해야 합니다. 이 예제는 Yocto로 생성된 특정 SDK 하나에만 적합합니다. CMAKE_C_COMPILER 및 CMAKE_CXX_COMPILER 도 마찬가지입니다.

저희는 PKG_CONFIG_*와 같은 환경 변수를 제공하는 래퍼 스크립트에 의존하지 않습니다. 대신, .pc 파일의 경로는 툴체인 파일에 명시됩니다. 다른 sysroot를 사용할 경우 PKG_CONFIG_LIBDIR 파일에서 조정이 필요할 가능성이 높습니다. 예를 들어, Raspberry Pi OS(구 Raspbian) 이미지에서 생성된 sysroot의 경우 대신 /usr/lib/arm-gnueabihf/pkgconfig 를 사용해야 합니다.

이 예제에서 제시된 컴파일러 및 링커 플래그는 반드시 최적의 설정은 아닙니다. 대상 기기에 맞게 필요에 따라 조정하십시오.

예제 툴체인 파일의 CMake 관련 세부 사항에 대한 자세한 내용은 이 블로그 게시물과 CMake 문서를 참조하십시오.

cmake_minimum_required(VERSION 3.18)
include_guard(GLOBAL)

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(TARGET_SYSROOT /home/user/rpi-sdk/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi)
set(CROSS_COMPILER /home/user/rpi-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi)

set(CMAKE_SYSROOT ${TARGET_SYSROOT})

set(ENV{PKG_CONFIG_PATH} "")
set(ENV{PKG_CONFIG_LIBDIR} ${CMAKE_SYSROOT}/usr/lib/pkgconfig:${CMAKE_SYSROOT}/usr/share/pkgconfig)
set(ENV{PKG_CONFIG_SYSROOT_DIR} ${CMAKE_SYSROOT})

set(CMAKE_C_COMPILER ${CROSS_COMPILER}/arm-poky-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER ${CROSS_COMPILER}/arm-poky-linux-gnueabi-g++)

set(QT_COMPILER_FLAGS "-march=armv7-a -mfpu=neon -mfloat-abi=hard")
set(QT_COMPILER_FLAGS_RELEASE "-O2 -pipe")
set(QT_LINKER_FLAGS "-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed")

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

include(CMakeInitializeConfigs)

function(cmake_initialize_per_config_variable _PREFIX _DOCSTRING)
  if (_PREFIX MATCHES "CMAKE_(C|CXX|ASM)_FLAGS")
    set(CMAKE_${CMAKE_MATCH_1}_FLAGS_INIT "${QT_COMPILER_FLAGS}")

    foreach (config DEBUG RELEASE MINSIZEREL RELWITHDEBINFO)
      if (DEFINED QT_COMPILER_FLAGS_${config})
        set(CMAKE_${CMAKE_MATCH_1}_FLAGS_${config}_INIT "${QT_COMPILER_FLAGS_${config}}")
      endif()
    endforeach()
  endif()

  if (_PREFIX MATCHES "CMAKE_(SHARED|MODULE|EXE)_LINKER_FLAGS")
    foreach (config SHARED MODULE EXE)
      set(CMAKE_${config}_LINKER_FLAGS_INIT "${QT_LINKER_FLAGS}")
    endforeach()
  endif()

  _cmake_initialize_per_config_variable(${ARGV})
endfunction()

대상 장치용 애플리케이션 빌드

Qt 빌드가 완료되고 스테이징 위치에 설치되면 예제나 애플리케이션을 빌드할 수 있습니다.

CMake를 사용하는 경우, 스테이징 위치(예:$HOME/qt6-rpi )의 bin 디렉터리에 생성된 qt-cmake 스크립트를 사용하여 구성한 다음, ninja 를 실행하십시오. 예:

$HOME/qt6-rpi/bin/qt-cmake .
cmake --build .

이렇게 생성된 애플리케이션 바이너리는 기기에 배포할 수 있습니다. qt-cmake 헬퍼 스크립트를 사용하면 Qt 빌드에 사용된 툴체인 파일이 자동으로 로드되므로, 애플리케이션마다 이를 반복해서 지정할 필요가 없어 편리합니다.

Qt 자체와는 달리, Qt 6.0에서는 적절한 기기 사양이 있고 Qt를 구성할 때 CMake나 configure에 적절한 레거시 인수가 전달된 경우, qmake를 사용한 애플리케이션 빌드가 여전히 지원됩니다. 이 조건들이 모두 충족된다면, qmake 및 make 를 실행해도 대상 기기용 애플리케이션 바이너리가 생성됩니다.

플랫폼 플러그인 및 EGLFS의 기본값

구성이 완료되면 기본 플랫폼 플러그인이 선택됩니다. 이 플러그인은 -platform 인수를 사용하지 않고 QT_QPA_PLATFORM 환경 변수도 설정되지 않은 상태에서 애플리케이션을 실행할 때 사용됩니다.

마찬가지로, EGLFS 플랫폼 플러그인에도 여러 백엔드가 있습니다. 기본값은 사용 가능 여부와 미리 정의된 우선순위 순서에 따라 선택됩니다. drm과 gbm을 모두 사용할 수 있는 경우, 기본값은 eglfs_kms 백엔드가 됩니다. 이는 실행 시 QT_QPA_EGLFS_INTEGRATION 환경 변수를 설정하여 언제든지 재정의할 수 있습니다.

실행 시 특정 값을 강제로 지정하지 않고 빌드 시 이러한 기본값을 변경하려면, CMake를 한 번 실행한 후 다음 두 가지 CMake 캐시 변수를 사용할 수 있습니다:

  • QT_QPA_DEFAULT_PLATFORM (STRING) - 기본 플랫폼 플러그인의 이름.
  • QT_QPA_DEFAULT_EGLFS_INTEGRATION (STRING) - 기본 EGLFS 백엔드.

이러한 변수는 툴체인 파일 내에서도 설정할 수 있습니다.

Qt 구성에 대한 자세한 내용은 Qt 구성 옵션을 참조하십시오.

© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.