Windows용 Qt - 배포

이 문서에서는 Windows용 배포 과정을 설명합니다. 배포 과정을 시연하기 위해 문서 전반에 걸쳐 'Plug & Paint' 예제 애플리케이션을 예로 들어 설명합니다.

Windows 배포 도구

Windows Deploy Qt에서 Qt 애플리케이션을 배포하는 데 권장되고 가장 쉬운 방법은 windeployqt 도구를 사용하는 것입니다. 이 도구는 필요한 모든 Qt 라이브러리, 플러그인, QML 모듈 및 런타임 종속성을 자동으로 수집하여 바로 실행 가능한 배포 폴더로 생성합니다.

이 도구는 Windows 데스크톱 애플리케이션을 위한 설치 트리를 생성하며, 이를 통해 설치 패키지로 쉽게 묶을 수 있습니다.

빌드 환경 설정

Qt Online Installer 을 통해 Qt를 설치한 경우, windeployqt를 실행하기 전에 빌드 환경을 설정해야 합니다. 이를 위해 다음 명령을 실행하십시오:

<qt-installation-folder>/bin/qtenv2.bat

사용법

windeployqt는 <qt-installation-folder>/bin/ 에 위치하며, .exe 파일이나 .exe 파일이 포함된 디렉터리를 인수로 받아 실행 파일의 종속성을 스캔합니다.

다음 사항에 유의하십시오:

• --qmldir 인자로 디렉터리가 전달된 경우, windeployqt는 qmlimportscanner 도구를 사용하여 해당 디렉터리 내의 QML 파일을 스캔해 QML 임포트 종속성을 확인합니다. 식별된 종속성은 실행 파일의 디렉터리로 복사됩니다.
• Qt가 ` -relocatable ` 구성 스위치를 비활성화한 상태로 빌드된 경우, windeployqt는 ` Qt6Core.dll ` 내의 고정된 로컬 경로를 상대 경로로 대체합니다.
• Windows 데스크톱 애플리케이션의 경우, windeployqt는 --no-compiler-runtime 가 지정되지 않은 한 기본적으로 필요한 컴파일러 런타임 파일을 복사합니다. Microsoft Visual C++를 사용하는 릴리스 빌드의 경우, 이는 해당 도구가 애플리케이션 설치 프로그램에 공식 Visual C++ 재배포 가능 패키지가 포함되어 있을 것으로 예상함을 의미합니다.

  재배포 패키지를 사용할 수 없는 경우, windeployqt는 개발자 컴퓨터에 있는 컴파일러의 공유 런타임 DLL을 대신 사용할 수 있습니다. 이러한 개별 DLL은 재배포를 목적으로 하거나 재배포가 허가된 것이 아니므로, 직접 배포해서는 안 됩니다. 최종 사용자 시스템에 배포할 때는 반드시 공식 Microsoft 재배포 가능 설치 프로그램만 사용해야 합니다.

일반적인 사용 사례

표준 Qt Widgets 애플리케이션 배포

windeployqt.exe .\build\MyApp.exe

QML 소스 코드가 포함된 Qt Quick 애플리케이션 배포

windeployqt.exe --qmldir .\qml .\build\MyApp.exe

패키징을 위한 appx 매니페스트 생성

응용 프로그램을 Windows appx 패키지로 패키징할 준비를 할 때 이 방법을 사용하십시오.

--appx 옵션은 AppxManifest.xml 파일을 생성하며, --appx-certificate 는 매니페스트에 포함할 인증서를 지정합니다.

windeployqt.exe --appx --appx-certificate MyCompany.cer .\build\MyApp.exe

시뮬레이션 실행

시뮬레이션 실행은 아무것도 복사하거나 업데이트하지 않고 배포 과정을 시뮬레이션합니다.

windeployqt.exe --dry-run MyApp.exe

옵션

일반

입력 및 출력 제어

Qt 경로 확인

빌드 구성

배포 동작

플러그인

QML

번역

시스템 및 런타임 구성 요소

출력된 파일 목록

정적 링크

정적 애플리케이션을 빌드하려면, 다음 명령어를 사용하여 Qt를 정적으로 구성한 후 빌드하십시오 -static:

cd C:\path\to\Qt
configure -static <any other options you need>

나중에 동일한 위치에서 Qt를 재구성하고 재빌드해야 하는 경우, 이전 구성의 모든 흔적이 제거되었는지 확인하십시오.

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

이 섹션에서는 예시로, 정적 방식으로 빌드된 Qt를 사용하여 Plug & Paint 예제를 빌드해 보겠습니다.

Qt 빌드가 완료되면 Plug & Paint 애플리케이션을 빌드합니다. 이 섹션에서는 정적 Qt 빌드가 C:\path\to \static \Qt 에 설치되어 있다고 가정합니다. 먼저 애플리케이션이 포함된 디렉터리로 이동해야 합니다:

cd examples\tools\plugandpaint

이제 빌드 디렉터리를 생성하고 qt-cmake 를 호출하여 빌드 시스템 파일을 생성합니다.

md build_static
cd build_static
C:\path\to\static\Qt\bin\qt-cmake .. -DCMAKE_BUILD_TYPE=Release -GNinja
ninja

아마도 릴리스 라이브러리를 링크하고 싶을 텐데, 이를 CMAKE_BUILD_TYPE 변수로 지정했습니다. 이제 모든 것이 오류 없이 컴파일되고 링크되었다면, 배포 준비가 된 plugandpaint.exe 파일이 생성되었을 것입니다. 애플리케이션에 필요한 라이브러리가 포함되어 있는지 확인하려면, Qt나 Qt 애플리케이션이 설치되어 있지 않은 컴퓨터로 실행 파일을 복사한 다음, 해당 컴퓨터에서 실행해 보십시오.

애플리케이션이 컴파일러 특정 라이브러리에 의존하는 경우, 이러한 라이브러리도 애플리케이션과 함께 재배포해야 한다는 점을 기억하십시오. depends 도구를 사용하여 애플리케이션이 어떤 라이브러리에 링크되어 있는지 확인할 수 있습니다. 자세한 내용은 ‘애플리케이션 종속성( Application Dependencies )’ 섹션을 참조하십시오.

정적 링크 방식을 사용해서는 플러그인을 배포할 수 없기 때문에, 지금까지 준비한 애플리케이션은 불완전합니다. 애플리케이션은 실행되지만, 플러그인이 누락되어 기능이 비활성화됩니다. 플러그인 기반 애플리케이션을 배포하려면 공유 라이브러리 방식을 사용해야 합니다.

공유 라이브러리

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

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

이 예제에서는 Qt가 공유 라이브러리로 설치되어 있다고 가정합니다. 이는 Qt 설치 시 기본 설정이며, C: \ \path \ \to \ \Qt 디렉터리에 위치합니다.

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

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

cd examples\tools\plugandpaint

이제 전용 빌드 디렉터리를 생성하고 ` qt-cmake `를 실행하여 빌드 시스템 파일을 생성합니다:

md build_shared
cd build_shared
C:\path\to\Qt\bin\qt-cmake .. -DCMAKE_BUILD_TYPE=Release -GNinja
ninja

오류 없이 모든 것이 컴파일되고 링크되었다면, ` plugandpaint.exe ` 실행 파일과 ` pnp_basictools.dll `, ` pnp_extrafilters.dll ` 플러그인 파일이 생성됩니다.

애플리케이션 패키지 생성

애플리케이션을 배포하려면, 관련 Qt DLL(애플리케이션에서 사용된 Qt 모듈에 해당하는)과 Windows 플랫폼 플러그인인 qwindows.dll, 그리고 실행 파일을 release 하위 디렉터리의 동일한 디렉터리 트리에 복사해야 합니다.

사용자 플러그인과는 달리, Qt 플러그인은 플러그인 유형에 해당하는 하위 디렉터리에 배치해야 합니다. 플랫폼 플러그인의 올바른 위치는 platforms 라는 이름의 하위 디렉터리입니다. ‘Qt 플러그인’ 섹션에는 플러그인에 대한 추가 정보와 Qt가 플러그인을 검색하는 방법에 대한 내용이 포함되어 있습니다.

동적 OpenGL을 사용하는 경우, 애플리케이션이 소프트웨어 기반 OpenGL과 호환된다면 필요한 라이브러리를 추가로 포함할 수 있습니다.

Qt가 ICU 또는 OpenSSL에 링크되도록 구성된 경우, 해당 DLL도 release 폴더에 추가해야 할 수 있습니다. 하지만 Windows용 Qt 바이너리 패키지의 경우 이 작업이 필요하지 않습니다. 특정 버전의 ICU 또는 OpenSSL로 Qt를 구성한 경우, windeployqt는 Qt의 ` [bin] ` 디렉터리 내에서 해당 라이브러리의 DLL을 찾을 수 있다면 이를 자동으로 인식합니다. 자세한 내용은 ‘타사 라이브러리’ 항목도 참조하십시오.

응용 프로그램이 컴파일러 특정 라이브러리에 의존하는 경우, 해당 라이브러리는 응용 프로그램과 함께 재배포되어야 한다는 점을 기억하십시오. depends 도구를 사용하여 응용 프로그램이 어떤 라이브러리에 링크되어 있는지 확인할 수 있습니다. 자세한 내용은 ‘응용 프로그램 종속성’ 섹션을 참조하십시오.

플러그인에 대해서는 잠시 후에 다루겠지만, 먼저 애플리케이션이 배포된 환경에서 정상적으로 작동하는지 확인해 보겠습니다: 실행 파일과 Qt DLL을 Qt나 Qt 애플리케이션이 설치되어 있지 않은 컴퓨터로 복사하거나, 빌드 컴퓨터에서 테스트하려는 경우 해당 컴퓨터의 환경에 Qt가 설치되어 있지 않은지 확인하십시오.

애플리케이션이 문제 없이 실행된다면, ‘ plugandpaint ’ 애플리케이션의 동적 링크 버전을 성공적으로 만든 것입니다. 하지만 관련 플러그인을 아직 배포하지 않았기 때문에 애플리케이션의 기능은 여전히 정상적으로 작동하지 않을 것입니다.

플러그인은 일반 DLL과는 작동 방식이 다르기 때문에, Qt DLL의 경우처럼 단순히 애플리케이션 실행 파일과 같은 디렉터리에 복사해 둘 수는 없습니다. 애플리케이션은 플러그인을 찾을 때, 애플리케이션 실행 파일 디렉터리 내의 ` plugins ` 하위 디렉터리를 검색합니다.

따라서 애플리케이션에서 플러그인을 사용할 수 있게 하려면, plugins 하위 디렉터리를 생성하고 관련 DLL 파일을 해당 디렉터리에 복사해야 합니다:

plugins\pnp_basictools.dll
plugins\pnp_extrafilters.dll

Plug & Paint 애플리케이션을 실행하는 데 필요한 모든 Qt DLL과 애플리케이션 전용 플러그인을 배포하는 아카이브에는 다음 파일들이 포함되어야 합니다:

애플리케이션에서 사용하는 기능에 따라 다른 플러그인이 필요할 수 있습니다(iconengines, imageformats).

또한, 아카이브에는 다음의 컴파일러별 라이브러리가 포함되어 있어야 합니다(Visual Studio 17 (2022) 기준):

동적 OpenGL을 사용한 경우, 아카이브에는 다음 항목이 추가로 포함될 수 있습니다:

마지막으로, Qt가 ICU를 사용하도록 구성된 경우, 아카이브에는 다음이 포함되어야 합니다:

이제 응용 프로그램을 성공적으로 배포할 수 있는지 확인하려면, Qt나 컴파일러가 설치되어 있지 않은 컴퓨터에서 이 아카이브를 추출한 후 실행해 보십시오.

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

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

플러그인을 사용하면 전체 애플리케이션 제품군에서 플러그인을 쉽게 활용할 수 있다는 장점이 있습니다.

대개는 애플리케이션의 main() 함수 내에서, QApplication 객체가 생성된 직후에 경로를 추가하는 것이 가장 편리합니다. 경로가 추가되면, 애플리케이션은 자체 디렉터리의 plugins 하위 디렉터리를 검색하는 것 외에도 해당 경로에서 플러그인을 검색하게 됩니다. 추가 경로는 개수에 제한 없이 얼마든지 추가할 수 있습니다.

Windows 애플리케이션 매니페스트 생성

Windows에서 빌드할 때, Qt는 실행 파일 대상에 대한 애플리케이션 매니페스트를 자동으로 생성하여 삽입합니다.

생성된 매니페스트:

• Windows 10 및 Windows 11 호환성을 선언합니다
• 긴 경로 인식 기능을 활성화합니다
• 애플리케이션 버전을 설정합니다( PROJECT_VERSION 참조)
• 프로젝트 식별자를 정의합니다
• 요청된 실행 수준 구성
• 링크러가 생성한 기본 매니페스트 비활성화 (/MANIFEST:NO)

대상 소스 파일에 사용자 정의 .manifest 파일이 이미 제공된 경우, Qt는 이를 재정의하지 않습니다.

Windows 10/11 호환성을 선언하면 다음을 포함한 최신 Windows 동작이 활성화됩니다:

• 최신 창 관리자 동작 선택적 적용
• 자식 창에 대한 WS_EX_LAYERED 지원(Windows 8부터 지원되었으나 호환성 인식에 따라 제한됨)
• 긴 경로 지원(260자 초과)
• 명시적인 실행 수준 구성

적절한 호환성 선언이 없으면 Windows에서 해당 애플리케이션에 레거시 동작을 적용할 수 있습니다.

기본 매니페스트 내용

애플리케이션 식별 정보

매니페스트에는 ` assemblyIdentity ` 요소가 포함되어 있습니다:

<assemblyIdentity
    type="win32"
    name="com.yourcompany.myapp"
    version="1.0.0.0"
    processorArchitecture="*" />

• name — 프로젝트 식별자
• version — 4부분으로 구성된 Windows 버전으로 정규화된 값

기본적으로 식별자는 다음과 같습니다:

com.yourcompany.<target_name>

QT_WINDOWS_APP_PROJECT_IDENTIFIER 속성을 사용하여 대상별로 이 식별자를 재정의할 수 있습니다:

set_target_properties(myapp PROPERTIES
    QT_WINDOWS_APP_PROJECT_IDENTIFIER "org.example.myapp"
)

Windows 애플리케이션 매니페스트에는 네 부분으로 구성된 버전 번호가 필요합니다:

Major.Minor.Build.Revision

각 세그먼트는 0에서 65535 사이의 정수여야 합니다.

이 값은 PROJECT_VERSION 에서 파생되며 다음과 같이 정규화됩니다:

• 값이 누락된 경우 → 다음 값으로 기본 설정됩니다. 1.0.0.0
• 세그먼트가 4개 미만인 경우 → 0으로 채움
• 세그먼트가 4개 초과일 경우 → 잘림
• 값이 0보다 작을 경우 → 0으로 제한
• 값이 65535보다 큰 경우 → 65535로 제한됨 (경고 메시지 출력)

예시:

2.3        -> 2.3.0.0
1.2.3.4.5  -> 1.2.3.4
70000.1    -> 65535.1.0.0

Windows 호환성

매니페스트는 Windows 10 및 Windows 11에 대한 지원을 선언합니다.

<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a} 이 GUID는 Windows 10, Windows 11, Windows Server 2016, Windows Server 2019 및 Windows Server 2022 운영 체제와 일치합니다.

자세한 정보: Microsoft 애플리케이션 매니페스트.

긴 경로 인식

<ws2:longPathAware>true</ws2:longPathAware>

운영 체제에서 지원하는 경우, 260자보다 긴 파일 경로를 사용할 수 있도록 합니다.

실행 수준

<requestedExecutionLevel level="asInvoker" uiAccess="false" />

기본 수준은 ` asInvoker`입니다.

실행 수준을 설정하려면 QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL 속성을 사용하십시오.

유효한 값:

• asInvoker (기본값)
• highestAvailable
• requireAdministrator

예시:

set_target_properties(myapp PROPERTIES
    QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL "requireAdministrator"
)

유효하지 않은 값이 제공되면 경고가 표시되고 ` asInvoker `가 사용됩니다.

사용자 정의 매니페스트 제공

실행 파일이 소스 코드에 이미 ` .manifest ` 파일을 포함하고 있는 경우, Qt는 매니페스트 파일을 감지하여 자동 생성을 건너뜁니다:

add_executable(myapp
    main.cpp
    myapp.manifest
)

전체 예제

다음 예제는 사용자 정의 식별자와 실행 수준을 가진 자동 생성된 매니페스트를 사용하는 Windows 실행 파일을 보여줍니다:

cmake_minimum_required(VERSION 3.21)
project(MyApp VERSION 2.5.1)

find_package(Qt6 REQUIRED COMPONENTS Core Widgets)

qt_add_executable(MyApp
    main.cpp
)

set_target_properties(MyApp PROPERTIES
    QT_WINDOWS_APP_PROJECT_IDENTIFIER "org.example.myapp"
    QT_WINDOWS_APP_PROJECT_EXECUTION_LEVEL "highestAvailable"
)

이 예제에서 생성된 매니페스트 버전은 다음과 같습니다:

2.5.1.0

qmake를 사용한 매니페스트 파일

Visual Studio로 컴파일된 애플리케이션을 배포할 때는 몇 가지 추가 단계를 거쳐야 합니다.

먼저, 애플리케이션을 링크할 때 생성된 매니페스트 파일을 복사해야 합니다. 이 매니페스트 파일에는 런타임 라이브러리 등 사이드-바이-사이드 어셈블리에 대한 애플리케이션의 종속성 정보가 포함되어 있습니다.

매니페스트 파일은 애플리케이션 실행 파일과 동일한 폴더에 복사해야 합니다. 공유 라이브러리(DLL)의 매니페스트 파일은 사용되지 않으므로 복사할 필요가 없습니다.

공유 라이브러리의 종속성이 이를 사용하는 애플리케이션과 다른 경우, 매니페스트 파일을 DLL 바이너리에 삽입해야 합니다. 매니페스트를 삽입하기 위해 다음과 같은 ` CONFIG ` 옵션을 사용할 수 있습니다:

embed_manifest_dll
embed_manifest_exe

두 옵션 모두 기본적으로 활성화되어 있습니다. embed_manifest_exe 를 제거하려면 다음을 추가하십시오.

CONFIG -= embed_manifest_exe

을 .pro 파일에 추가하십시오.

매니페스트 파일 및 사이드바이사이드 어셈블리에 대한 자세한 내용은 사이드바이사이드 어셈블리 문서 페이지에서 확인할 수 있습니다.

애플리케이션에 런타임 라이브러리를 포함시키는 올바른 방법은 해당 라이브러리가 최종 사용자의 시스템에 설치되어 있는지 확인하는 것입니다.

최종 사용자의 시스템에 런타임 라이브러리를 설치하려면, 애플리케이션에 적절한 Visual C++ 재배포 가능 패키지(VCRedist) 실행 파일을 포함시키고, 사용자가 애플리케이션을 설치할 때 해당 파일이 실행되도록 해야 합니다.

이 재배포 패키지의 이름은 ‘ vc_redist.x64.exe (64비트)’이며, ‘ <Visual Studio install path>/VC/redist/<language-code> ’ 폴더에서 찾을 수 있습니다.

또는 웹에서 다운로드할 수도 있습니다(예: https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads).

애플리케이션 종속성

추가 라이브러리

구성에 따라, 컴파일러 전용 라이브러리를 애플리케이션과 함께 재배포해야 합니다.

Dependency Walker 도구를 사용하면 애플리케이션이 어떤 라이브러리에 링크되어 있는지 확인할 수 있습니다. 다음과 같이 실행하기만 하면 됩니다:

depends <application executable>

그러면 애플리케이션이 의존하고 있는 라이브러리 목록과 기타 정보가 표시됩니다.

depends ( ) 도구를 사용하여 Plug & Paint 실행 파일(plugandpaint.exe)의 릴리스 빌드를 확인해 보면, 이 도구는 비시스템 라이브러리에 대한 다음과 같은 직접적인 종속성을 나열합니다:

플러그인 DLL을 살펴보면 정확히 동일한 종속성이 나열되어 있습니다.

Qt 플러그인

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

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

Qt가 ` -relocatable ` 구성 스위치를 비활성화한 상태로 빌드되지 않은 한, 라이브러리는 재배치 가능합니다. Qt 플러그인의 검색 경로는 ` QtCore ` 라이브러리의 위치를 기준으로 하며, 대상 시스템에 애플리케이션을 설치한 후 플러그인이 제대로 발견되도록 하기 위해 별도의 조치가 필요하지 않습니다.

재배치 불가능한 빌드를 사용할 때 플러그인이 제대로 검색되도록 하기

재배치 불가능한 빌드의 경우, 애플리케이션을 대상 시스템에 설치한 후 플러그인이 제대로 인식되도록 하기 위해 추가적인 조치가 필요합니다.

이 경우, Qt 플러그인의 검색 경로는 ` QtCore ` 라이브러리에 하드코딩되어 있습니다. 기본적으로 Qt 설치 디렉터리의 `plugins` 하위 디렉터리가 첫 번째 플러그인 검색 경로입니다. 그러나 기본 경로와 같이 미리 정해진 경로에는 몇 가지 단점이 있습니다. 예를 들어, 대상 시스템에 해당 경로가 존재하지 않을 수 있습니다. 따라서 Qt 플러그인이 확실히 검색될 수 있도록 다양한 대안을 검토해야 합니다:

• qt.conf 를 사용합니다. 이 방법은 서로 다른 위치에 있는 실행 파일들이 동일한 플러그인을 공유하는 경우 권장됩니다.
• QApplication::addLibraryPath() 또는 QApplication::setLibraryPaths()을 사용하는 방법. 이 방법은 플러그인을 사용할 실행 파일이 하나뿐인 경우에 권장됩니다.
• 타사 설치 유틸리티를 사용하여 QtCore 라이브러리의 고정 경로를 변경하는 방법.

QApplication::addLibraryPath를 사용하여 사용자 정의 경로를 추가하는 경우 다음과 같이 보일 수 있습니다:

QCoreApplication::addLibraryPath("C:/customPath/plugins");

그러면 QCoreApplication::libraryPaths()은 다음과 같은 결과를 반환할 것입니다:

• C:/customPath/plugins
• C:/Qt/%VERSION%/plugins
• E:/myApplication/directory

실행 파일은 QCoreApplication::libraryPaths()가 반환한 QStringList 와 동일한 순서대로 이 디렉터리들에서 플러그인을 검색합니다. 새로 추가된 경로는 QCoreApplication::libraryPaths()의 맨 앞에 추가되므로, 이 경로가 가장 먼저 검색됩니다. 하지만 QCoreApplication::setLibraryPaths()를 사용하면 어떤 경로를 어떤 순서로 검색할지 직접 지정할 수 있습니다.

'Qt 플러그인 생성 방법' 문서에는 Qt 애플리케이션용 플러그인을 빌드하고 배포할 때 주의해야 할 사항들이 요약되어 있습니다.