Linux/X11용 Qt - 배포

이 문서에서는 Linux/X11용 Qt의 특정 배포 문제에 대해 설명합니다. Qt 소스 패키지와 함께 제공되는 플러그 앤 페인트 예제 애플리케이션을 배포하는 절차를 설명합니다.

유닉스 시스템(상용 유닉스, 리눅스 배포판 등)의 확산으로 인해 유닉스에서의 배포는 복잡한 주제입니다. 시작하기 전에 한 Unix 버전용으로 컴파일된 프로그램은 다른 Unix 시스템에서 실행되지 않을 수 있다는 점에 유의하세요. 예를 들어 크로스 컴파일러를 사용하지 않는 한 Irix에서 애플리케이션을 컴파일하여 AIX에 배포할 수 없습니다.

정적 링크

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

정적으로 Qt 빌드하기

이 접근 방식을 사용하려면 먼저 _정적_ 버전의 Qt 라이브러리를 빌드해야 합니다. Linux/X11용 Qt - 소스에서 빌드하기의 단계를 따르되, -static 인수를 추가하여 구성하는 것을 잊지 마세요:

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

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

Qt가 정적으로 빌드되면 다음 단계는 메이크파일을 재생성하고 애플리케이션을 다시 빌드하는 것입니다. 먼저 애플리케이션이 들어 있는 디렉토리로 이동해야 합니다:

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

이제 qmake를 실행하여 애플리케이션에 대한 새 메이크파일을 생성하고 클린 빌드를 수행하여 정적으로 링크된 실행 파일을 생성합니다:

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

릴리스 라이브러리에 대해 링크하고 싶을 수 있으며 qmake 을 호출할 때 이를 지정할 수 있습니다. 방금 빌드한 정적 Qt의 경로를 설정해야 한다는 점에 유의하세요.

애플리케이션이 실제로 Qt와 정적으로 링크되는지 확인하려면 ldd 도구(대부분의 Unices에서 사용 가능)를 실행합니다:

ldd ./application

출력에 Qt 라이브러리가 언급되지 않는지 확인합니다.

이제 모든 것이 오류 없이 컴파일되고 링크되었다면 배포할 준비가 된 plugandpaint 파일이 있을 것입니다. 애플리케이션이 실제로 독립적으로 실행될 수 있는지 확인하는 한 가지 쉬운 방법은 Qt 또는 Qt 애플리케이션이 설치되지 않은 머신에 복사하여 해당 머신에서 실행하는 것입니다.

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

플러그 앤 페인트 예제는 여러 구성 요소로 이루어져 있습니다: 핵심 애플리케이션(플러그 앤 페인트), 기본 도구 및 추가 필터 플러그인. 정적 링크 방식을 사용하여 플러그인을 배포할 수 없으므로 지금까지 준비한 실행 파일은 불완전합니다. 애플리케이션은 실행되지만 누락된 플러그인으로 인해 기능이 비활성화됩니다. 플러그인 기반 애플리케이션을 배포하려면 공유 라이브러리 접근 방식을 사용해야 합니다.

공유 라이브러리

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

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

Qt를 설치할 때 기본값인 공유 라이브러리로 /path/to/Qt 디렉터리에 이미 설치했다고 가정합니다.

애플리케이션을 Qt를 공유 라이브러리로 링크하기

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

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

이제 qmake를 실행하여 애플리케이션의 새 메이크파일을 생성하고 클린 빌드를 수행하여 동적으로 링크된 실행 파일을 생성합니다:

make clean
qmake -config release
make

이렇게 하면 핵심 애플리케이션이 빌드되고 다음은 플러그인을 빌드합니다:

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

모든 것이 오류 없이 컴파일되고 링크되면 plugandpaint 실행 파일과 libpnp_basictools.so 및 libpnp_extrafilters.so 플러그인 파일을 얻게 됩니다.

애플리케이션 패키지 만들기

Unix에는 표준 패키지 관리가 없으므로 아래에 제시하는 방법은 일반적인 솔루션입니다. 패키지를 만드는 방법에 대한 자세한 내용은 대상 시스템의 설명서를 참조하세요.

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

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

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

  참고: 애플리케이션이 '실행 시 사용자 ID 설정'으로 실행되고 루트가 소유하는 경우 일부 플랫폼에서는 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 디렉터리에 수동으로 복사하거나 플러그인의 프로젝트 파일에 DESTDIR 을 설정할 수 있습니다:

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

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

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

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

이제 애플리케이션을 성공적으로 배포할 수 있는지 확인하려면 Qt가 없고 컴파일러가 설치되지 않은 시스템에서 이 아카이브를 추출하고 plugandpaint.sh 스크립트를 실행하여 실행해 볼 수 있습니다.

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

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

애플리케이션 종속성

추가 라이브러리

애플리케이션이 어떤 라이브러리에 의존하는지 확인하려면 ldd 도구(대부분의 Unices에서 사용 가능)를 실행하세요:

ldd ./application

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

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

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

FontConfig와 FreeType은 항상 사용 가능하지 않거나 항상 바이너리 호환이 되지 않는 라이브러리의 다른 예입니다. 이상하게 들릴지 모르지만 일부 소프트웨어 공급업체는 아주 오래된 컴퓨터에서 소프트웨어를 컴파일하여 성공을 거둔 적이 있으며, 그 컴퓨터에서 실행 중인 소프트웨어를 업그레이드하지 않도록 매우 주의하고 있습니다.

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

Qt 플러그인

모든 Qt GUI 응용 프로그램에는 Qt에서 Qt 플랫폼 추상화 (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 애플리케이션용 플러그인을 빌드하고 배포할 때 주의해야 할 문제를 간략하게 설명합니다.