Linux용 Qt - 배포

이 문서는 Linux용 Qt의 구체적인 배포 관련 문제를 다룹니다. Qt 소스 패키지에 포함된 Plug & Paint 예제 애플리케이션을 배포하는 절차를 예시로 설명하겠습니다.

상용 유닉스나 리눅스 배포판과 같은 다양한 유닉스 시스템이 널리 보급됨에 따라, 유닉스 환경에서의 배포는 복잡한 주제입니다. 시작하기 전에, 특정 유닉스 변형용으로 컴파일된 프로그램은 다른 유닉스 시스템에서는 실행되지 않을 가능성이 높다는 점을 유의하십시오. 예를 들어, 크로스 컴파일러를 사용하지 않는 한 Irix에서 애플리케이션을 컴파일하여 AIX에 배포할 수는 없습니다.

공유 라이브러리

공유 라이브러리 방식을 사용하여 ‘ plugandpaint ’ 애플리케이션을 배포할 때 두 가지 과제가 있습니다. Qt 런타임을 애플리케이션 실행 파일과 함께 올바르게 재배포해야 하며, 애플리케이션이 플러그인을 찾을 수 있도록 대상 시스템의 올바른 위치에 플러그인을 설치해야 합니다.

Qt를 공유 라이브러리로 빌드하기

/path/to/Qt 디렉터리에 Qt가 공유 라이브러리 형태로 이미 설치되어 있다고 가정합니다. 이는 Qt를 설치할 때의 기본 설정입니다.

애플리케이션을 공유 라이브러리 형태의 Qt에 연결하기

Qt가 공유 라이브러리로 빌드되었는지 확인한 후, plugandpaint 애플리케이션을 빌드할 수 있습니다. 먼저, 애플리케이션이 있는 디렉터리로 이동해야 합니다:

cd /path/to/Qt/examples/tools/plugandpaint

이제 qmake를 실행하여 애플리케이션용 새 makefile을 생성하고, clean 빌드를 수행하여 동적 링크 실행 파일을 생성합니다:

make clean
qmake -config release
make

이렇게 하면 핵심 애플리케이션이 빌드되며, 다음 명령을 실행하면 플러그인이 빌드됩니다:

cd ../plugandpaint/plugins
make clean
qmake -config release
make

모든 것이 오류 없이 컴파일 및 링크되었다면, ‘ plugandpaint ’ 실행 파일과 ‘ libpnp_basictools.so ’, ‘ libpnp_extrafilters.so ’ 플러그인 파일을 얻을 수 있습니다.

애플리케이션 패키지 생성

유닉스에는 표준 패키지 관리 시스템이 없으므로, 아래에서 소개하는 방법은 일반적인 해결책입니다. 패키지 생성 방법에 대한 정보는 대상 시스템의 문서를 참조하십시오.

애플리케이션을 배포하려면, 관련 Qt 라이브러리(애플리케이션에서 사용되는 Qt 모듈에 해당하는 것), 플랫폼 플러그인 및 실행 파일을 동일한 디렉터리 트리에 복사해야 합니다. 애플리케이션이 컴파일러 특정 라이브러리에 의존하는 경우, 이러한 라이브러리도 애플리케이션과 함께 재배포해야 한다는 점을 기억하십시오. 자세한 내용은 '애플리케이션 종속성' 섹션을 참조하십시오.

플러그인에 대해서는 잠시 후에 다루겠지만, 공유 라이브러리의 주요 문제는 동적 링크기가 Qt 라이브러리를 찾을 수 있도록 해야 한다는 점입니다. 별도로 지정하지 않는 한, 동적 링크기는 애플리케이션이 위치한 디렉터리를 검색하지 않습니다. 이 문제를 해결하는 방법은 여러 가지가 있습니다:

• Qt 라이브러리를 시스템 라이브러리 경로 중 하나(예: 대부분의 시스템에서 /usr/lib )에 설치할 수 있습니다.
• 애플리케이션을 링크할 때 ` -rpath ` 명령줄 옵션에 미리 정해진 경로를 전달할 수 있습니다. 이렇게 하면 애플리케이션이 시작될 때 동적 링커가 해당 디렉터리를 검색하도록 지시하게 됩니다.
• 애플리케이션용 시작 스크립트를 작성하여 동적 링커 설정을 수정할 수 있습니다(예: LD_LIBRARY_PATH 환경 변수에 애플리케이션 디렉터리를 추가하는 방식).

  참고: 애플리케이션이 "실행 시 사용자 ID 설정"으로 실행되고 소유자가 root인경우 , 일부 플랫폼에서는 LD_LIBRARY_PATH가 무시됩니다. 이 경우 LD_LIBRARY_PATH 방식을 사용할 수 없습니다.

첫 번째 방법의 단점은 사용자가 슈퍼 유저 권한을 가져야 한다는 점입니다. 두 번째 방법의 단점은 사용자가 미리 정해진 경로에 설치할 권한이 없을 수 있다는 점입니다. 두 경우 모두 사용자는 자신의 홈 디렉터리에 설치할 수 있는 선택권이 없습니다. 세 번째 방식이 가장 유연하므로 이를 사용하는 것을 권장합니다. 예를 들어, ` plugandpaint.sh ` 스크립트는 다음과 같이 작성됩니다:

#!/bin/sh
appname=`basename $0 | sed s,\.sh$,,`

dirname=`dirname $0`
tmp="${dirname#?}"

if [ "${dirname%$tmp}" != "/" ]; then
dirname=$PWD/$dirname
fi
LD_LIBRARY_PATH=$dirname
export LD_LIBRARY_PATH
$dirname/$appname "$@"

실행 파일 대신 이 스크립트를 실행하면 동적 링커가 Qt 라이브러리를 확실히 찾을 수 있습니다. 다른 애플리케이션에서 사용하려면 스크립트의 이름만 변경하면 된다는 점에 유의하십시오.

플러그인을 찾을 때, 애플리케이션은 애플리케이션 실행 파일 디렉터리 내의 plugins 하위 디렉터리를 검색합니다. 플러그인을 plugins 디렉터리에 수동으로 복사하거나, 플러그인 프로젝트 파일에서 ` DESTDIR `을 설정할 수 있습니다:

DESTDIR = /path/to/Qt/plugandpaint/plugins

plugandpaint 애플리케이션을 실행하는 데 필요한 모든 Qt 라이브러리와 플러그인을 배포하는 아카이브에는 다음 파일들이 포함되어야 합니다:

대부분의 시스템에서 공유 라이브러리의 확장자는 .so 입니다. 주목할 만한 예외는 HP-UX로, 이 시스템에서는 .sl 를 사용합니다.

애플리케이션이 컴파일러 특정 라이브러리에 의존하는 경우, 이러한 라이브러리는 여전히 애플리케이션과 함께 재배포되어야 한다는 점을 기억하십시오. 자세한 내용은 ‘애플리케이션 종속성’ 섹션을 참조하십시오.

이제 애플리케이션이 성공적으로 배포될 수 있는지 확인하려면, Qt나 컴파일러가 설치되어 있지 않은 컴퓨터에서 이 아카이브를 추출한 후, plugandpaint.sh 스크립트를 실행해 보십시오.

플러그인을 plugins 하위 디렉터리에 넣는 대신, QApplication::addLibraryPath() 또는 QApplication::setLibraryPaths()을 사용하여 애플리케이션을 시작할 때 사용자 정의 검색 경로를 추가할 수도 있습니다.

QCoreApplication::addLibraryPath("/some/other/path");

정적 링크

정적 링크는 Qt 라이브러리를 배포하고 대상 시스템의 라이브러리 기본 검색 경로에 라이브러리가 위치하도록 해야 하는 번거로움을 덜어주기 때문에, Unix에서 애플리케이션을 배포하는 데 있어 가장 안전하고 쉬운 방법인 경우가 많습니다.

Qt 정적 링크 빌드

이 방법을 사용하려면 먼저 Qt 라이브러리의 _정적_ 버전을 빌드해야 합니다. ‘Qt for Linux - 소스에서 빌드하기’의 단계를 따르되, configure에 -static 인수를 추가하는 것을 잊지 마십시오:

mkdir -p ~/dev/qt-build
cd ~/dev/qt-build
/tmp/qt-everywhere-src-6.12.0/configure -static

애플리케이션을 정적 버전 Qt에 링크하기

Qt가 정적으로 빌드되면, 다음 단계는 makefile을 재생성하고 애플리케이션을 재빌드하는 것입니다. 먼저, 애플리케이션이 포함된 디렉토리로 이동해야 합니다:

cd /path/to/Qt/examples/widgets/tools/plugandpaint/app

이제 qmake를 실행하여 애플리케이션용 새 makefile을 생성하고, clean 빌드를 수행하여 정적 링크된 실행 파일을 생성합니다:

make clean
PATH=/path/to/Qt/bin:$PATH
export PATH
qmake -config release
make

대부분 릴리스 라이브러리를 사용하여 링크하고 싶을 텐데, qmake 를 실행할 때 이를 지정할 수 있습니다. 방금 빌드한 정적 Qt의 경로를 설정해야 한다는 점에 유의하십시오.

애플리케이션이 실제로 Qt와 정적 링크되었는지 확인하려면 ldd 도구(대부분의 유닉스 시스템에서 사용 가능)를 실행하십시오:

ldd ./application

출력 결과에 Qt 라이브러리가 언급되지 않았는지 확인하십시오.

이제 모든 것이 오류 없이 컴파일 및 링크되었다면, 배포 준비가 완료된 plugandpaint 파일이 생성되었을 것입니다. 애플리케이션이 실제로 독립적으로 실행될 수 있는지 확인하는 쉬운 방법 중 하나는 Qt나 Qt 기반 애플리케이션이 설치되지 않은 컴퓨터로 애플리케이션을 복사한 후, 해당 컴퓨터에서 실행해 보는 것입니다.

애플리케이션이 컴파일러 특정 라이브러리에 의존하는 경우, 해당 라이브러리는 애플리케이션과 함께 재배포되어야 한다는 점을 기억하십시오. 자세한 내용은 ‘애플리케이션 종속성’ 섹션을 참조하십시오.

Plug & Paint 예제는 핵심 애플리케이션(Plug & Paint)과 Basic Tools 및 Extra Filters 플러그인 등 여러 구성 요소로 이루어져 있습니다. 정적 링크 방식을 사용해서는 플러그인을 배포할 수 없기 때문에, 지금까지 준비한 실행 파일은 불완전합니다. 응용 프로그램은 실행되지만, 플러그인이 없기 때문에 기능은 사용되지 않습니다. 플러그인 기반 응용 프로그램을 배포하려면 공유 라이브러리 방식을 사용해야 합니다.

애플리케이션 종속성

추가 라이브러리

애플리케이션이 어떤 라이브러리에 의존하는지 확인하려면, ` ldd ` 도구(대부분의 유닉스 시스템에서 사용 가능)를 실행하십시오:

ldd ./application

그러면 애플리케이션에 필요한 모든 공유 라이브러리 종속성이 나열됩니다. 구성에 따라, 이러한 라이브러리는 애플리케이션과 함께 재배포되어야 합니다. 특히, 시스템 컴파일러와 바이너리 호환성이 없는 컴파일러로 애플리케이션을 컴파일하는 경우 표준 C++ 라이브러리를 반드시 재배포해야 합니다. 가능한 경우, 이러한 라이브러리를 정적으로 링크하는 것이 가장 안전한 해결책입니다.

일부 구현체에서는 ` dlopen()`를 통해 다른 공유 라이브러리를 열려고 시도할 수 있으며, 이 작업이 실패할 경우 X11 라이브러리로 인해 애플리케이션이 충돌할 수 있으므로, 일반적인 X11 라이브러리는 동적으로 링크하는 것이 좋습니다.

또한 Qt는 Xinerama나 Xrandr과 같은 특정 X11 확장 기능을 검색하여, 해당 확장 기능이 링크된 모든 라이브러리를 포함하여 불러올 수 있다는 점도 언급할 가치가 있습니다. 특정 확장 기능의 존재를 보장할 수 없다면, Qt를 구성할 때 해당 기능을 비활성화하는 것이 가장 안전한 방법입니다(예: ./configure -no-xrandr).

FontConfig와 FreeType 역시 항상 사용 가능하거나 바이너리 호환성이 보장되지 않는 라이브러리의 또 다른 예입니다. 이상하게 들릴지 모르겠지만, 일부 소프트웨어 공급업체들은 매우 오래된 컴퓨터에서 소프트웨어를 컴파일하고, 그 컴퓨터에서 실행되는 소프트웨어를 절대 업그레이드하지 않도록 각별히 주의함으로써 성공을 거두기도 했습니다.

애플리케이션을 정적 Qt 라이브러리에 링크할 때는 앞서 언급한 종속 라이브러리를 명시적으로 링크해야 합니다. 이를 위해 프로젝트 파일의 LIBS 변수에 해당 라이브러리를 추가하십시오.

Qt 플러그인

모든 Qt GUI 애플리케이션은 Qt에서 Qt Platform Abstraction (QPA) 계층을 구현하는 플러그인이 필요합니다. Linux/X11의 경우, 플랫폼 플러그인의 이름은 ` libqxcb.so`입니다. 이 파일은 배포판 디렉터리 내의 특정 하위 디렉터리(기본값: ` platforms`)에 위치해야 합니다. 또는 아래에 설명된 대로 Qt가 플러그인을 찾기 위해 사용하는 검색 경로를 조정할 수도 있습니다.

또한 애플리케이션은 JPEG 이미지 형식 플러그인이나 SQL 드라이버 플러그인과 같은 하나 이상의 Qt 플러그인에 의존할 수도 있습니다. 필요한 모든 Qt 플러그인을 애플리케이션과 함께 배포해야 합니다. 플랫폼 플러그인과 마찬가지로, 각 유형의 플러그인은 배포 디렉터리 내의 특정 하위 디렉터리(예: imageformats 또는 sqldrivers)에 위치해야 합니다.

Qt 플러그인에 대한 검색 경로(및 몇 가지 다른 경로)는 QtCore 라이브러리에 하드코딩되어 있습니다. 기본적으로 첫 번째 플러그인 검색 경로는 /path/to/Qt/plugins 로 하드코딩됩니다. 앞서 언급한 바와 같이, 미리 정해진 경로를 사용하는 데는 몇 가지 단점이 있으므로, Qt 플러그인이 제대로 검색될 수 있도록 다양한 대안을 검토해야 합니다.

• qt.conf 를 사용합니다. 이 방법은 가장 높은 유연성을 제공하므로 권장되는 접근 방식입니다.
• QApplication::addLibraryPath() 또는 QApplication::setLibraryPaths()을 사용합니다.
• 타사 설치 유틸리티나 대상 시스템의 패키지 관리자를 사용하여 QtCore 라이브러리의 하드코딩된 경로를 변경하는 방법.

'Qt 플러그인 생성 방법' 문서는 Qt 애플리케이션용 플러그인을 빌드하고 배포할 때 주의해야 할 사항을 설명합니다.

실습: DEB 패키지 만들기

이 섹션에서는 Qt 6.5 이상에서 사용할 수 있는 CMake 배포 API를 사용하여 Linux에서 Qt 애플리케이션용 DEB 패키지를 만드는 방법을 설명합니다. 전용 linuxdeployqt 도구는 없습니다. 현재 솔루션은 CMake의 내장 기능에만 의존합니다.

예제 프로젝트 설정

간단한 CMake 프로젝트로 시작합니다:

cmake_minimum_required(VERSION 3.22)
project(MyApp)

find_package(Qt6 REQUIRED COMPONENTS Widgets)
qt_standard_project_setup()

qt_add_executable(MyApp main.cpp)
target_link_libraries(MyApp PRIVATE Qt::Widgets)

1단계: 설치 준비

애플리케이션을 설치하고, 독립형 디렉터리를 생성하는 배포 스크립트를 생성하는 명령어를 추가합니다:

# Install the executable to "${CMAKE_INSTALL_PREFIX}/bin".
install(TARGETS MyApp
    BUNDLE  DESTINATION .
    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
)

# Generate the deployment script for MyApp.
qt_generate_deploy_app_script(
    TARGET MyApp
    FILENAME_VARIABLE deploy_script
    NO_UNSUPPORTED_PLATFORM_ERROR
)

# Run the deployment script during installation (on "cmake --install").
install(SCRIPT ${deploy_script})

프로젝트를 빌드하고 설치합니다:

qt-cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/tmp/my-application ..
cmake --build .
cmake --install .

배포 스크립트:

• 실행 파일 옆에 디렉터리 구조에 대한 정보가 포함된 qt.conf 파일을 생성합니다. 이는 실행 시 플러그인과 자산을 찾는 데 필요합니다. 자세한 내용은 qt.conf 문서를 참조하십시오.
• CMake의 내장 함수(GET_RUNTIME_DEPENDENCIES)를 사용하여 실행 파일과 사용된 Qt 플러그인을 분석하여 배포할 Qt 라이브러리를 결정합니다.
• 필요한 Qt 플러그인과 Qt 라이브러리를 설치합니다.

이제 설치 디렉터리를 다른 컴퓨터로 복사해도 애플리케이션이 정상적으로 작동합니다.

2단계: DEB 패키지 생성

설치가 완료되면 CPack을 사용하여 디렉터리를 패키징합니다. CMake 프로젝트에 다음 내용을 추가하십시오:

set(CPACK_PACKAGE_NAME my-app)
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "My amazing application")
set(CPACK_PACKAGE_VENDOR "My Company")
set(CPACK_PACKAGE_INSTALL_DIRECTORY ${CPACK_PACKAGE_NAME})
set(CPACK_VERBATIM_VARIABLES ON)
set(CPACK_PACKAGING_INSTALL_PREFIX "/opt/myapp")
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "Package Maintainer <maintainer@example.com>")
set(CPACK_DEBIAN_PACKAGE_DEPENDS libc6 libstdc++6 libgcc-s1)
include(CPack)

프로젝트를 재구성하고, 빌드 디렉터리로 이동한 후(해당 디렉터리에는 CPackConfig.cmake 파일이 포함되어 있어야 함), CPack을 실행하여 DEB 패키지를 생성합니다:

cpack -G DEB

패키지 내용을 확인하려면:

dpkg -c my_app-1.0-Linux.deb

패키지를 설치하려면:

sudo dpkg -i my_app-1.0-Linux.deb