Sophie

Sophie

distrib > Fedora > 18 > i386 > by-pkgid > 5ab010e37991249ab4adaa24d6e39c6e > files > 29

qt5-qtdoc-5.1.1-2.fc18.noarch.rpm

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en_US" lang="en_US">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!-- deployment.qdoc -->
  <title>Deploying an Application on Windows | QtDoc 5.1</title>
  <link rel="stylesheet" type="text/css" href="style/offline.css" />
</head>
<body>
<div class="header" id="qtdocheader"></div>
<div class="content">
<div class="line">
<div class="content mainContent">
<p class="naviNextPrevious headerNavi">
</p><p/>
<div class="toc">
<h3><a name="toc">Contents</a></h3>
<ul>
<li class="level1"><a href="#static-linking">Static Linking</a></li>
<li class="level2"><a href="#building-qt-statically">Building Qt Statically</a></li>
<li class="level2"><a href="#linking-the-application-to-the-static-version-of-qt">Linking the Application to the Static Version of Qt</a></li>
<li class="level1"><a href="#shared-libraries">Shared Libraries</a></li>
<li class="level2"><a href="#building-qt-as-a-shared-library">Building Qt as a Shared Library</a></li>
<li class="level2"><a href="#linking-the-application-to-qt-as-a-shared-library">Linking the Application to Qt as a Shared Library</a></li>
<li class="level2"><a href="#creating-the-application-package">Creating the Application Package</a></li>
<li class="level2"><a href="#manifest-files">Manifest files</a></li>
<li class="level2"><a href="#manual-installations-with-visual-studio-2008-and-2010">Manual installations with Visual Studio 2008 and 2010</a></li>
<li class="level1"><a href="#application-dependencies">Application Dependencies</a></li>
<li class="level2"><a href="#additional-libraries">Additional Libraries</a></li>
<li class="level2"><a href="#qt-plugins">Qt Plugins</a></li>
<li class="level1"><a href="#related-third-party-resources">Related Third Party Resources</a></li>
</ul>
</div>
<h1 class="title">Deploying an Application on Windows</h1>
<span class="subtitle"></span>
<!-- $$$deployment-windows.html-description -->
<div class="descr"> <a name="details"></a>
<p>This documentation will describe how to determine which files you should include in your distribution, and how to make sure that the application will find them at run-time. We will demonstrate the procedures in terms of deploying the Plug &amp; Paint application that is provided in Qt's examples directory.</p>
<p>Contents:</p>
<a name="static-linking"></a>
<h2>Static Linking</h2>
<p>If you want to keep things simple by only having a few files to deploy, i.e&#x2e; a stand-alone executable with the associated compiler specific DLLs, then you must build everything statically.</p>
<a name="building-qt-statically"></a>
<h3>Building Qt Statically</h3>
<p>Before we can build our application we must make sure that Qt is built statically. To do this, go to a command prompt and type the following:</p>
<pre class="cpp">cd C:\path\to\<span class="type">Qt</span>
configure <span class="operator">-</span><span class="keyword">static</span> <span class="operator">&lt;</span>any other options you need<span class="operator">&gt;</span></pre>
<p>Remember to specify any other options you need, such as data base drivers, as arguments to <tt>configure</tt>. Once <tt>configure</tt> has finished, type the following:</p>
<pre class="cpp">nmake sub<span class="operator">-</span>src</pre>
<p>This will build Qt statically. Note that we have used <tt>nmake</tt> in all the examples, but <tt>mingw32-make</tt> should be used for <a href="http://www.mingw.org/">MinGW</a>.</p>
<p><b>Note: </b>If you later need to reconfigure and rebuild Qt from the same location, ensure that all traces of the previous configuration are removed by entering the build directory and typing <tt>nmake distclean</tt> before running <tt>configure</tt> again.</p><a name="linking-the-application-to-the-static-version-of-qt"></a>
<h3>Linking the Application to the Static Version of Qt</h3>
<p>Once Qt has finished building we can build the Plug &amp; Paint application. First we must go into the directory that contains the application:</p>
<pre class="cpp">cd examples\tools\plugandpaint</pre>
<p>We must then run <tt>qmake</tt> to create a new makefile for the application, and do a clean build to create the statically linked executable:</p>
<pre class="cpp">nmake clean
qmake <span class="operator">-</span>config release
nmake</pre>
<p>You probably want to link against the release libraries, and you can specify this when invoking <tt>qmake</tt>. Now, provided that everything compiled and linked without any errors, we should have a <tt>plugandpaint.exe</tt> file that is ready for deployment. One easy way to check that the application really can be run stand-alone is to copy it to a machine that doesn't have Qt or any Qt applications installed, and run it on that machine.</p>
<p>Remember that if your application depends on compiler specific libraries, these must still be redistributed along with your application. You can check which libraries your application is linking against by using the <tt>depends</tt> tool. For more information, see the <a href="#application-dependencies">Application Dependencies</a> section.</p>
<p>The Plug &amp; Paint example consists of several components: The application itself (Plug &amp; Paint), and the Basic Tools and Extra Filters plugins. Since we cannot deploy plugins using the static linking approach, the application we have prepared is incomplete. It will run, but the functionality will be disabled due to the missing plugins. To deploy plugin-based applications we should use the shared library approach.</p>
<a name="shared-libraries"></a>
<h2>Shared Libraries</h2>
<p>We have two challenges when deploying the Plug &amp; Paint application using the shared libraries approach: The Qt runtime has to be correctly redistributed along with the application executable, and the plugins have to be installed in the correct location on the target system so that the application can find them.</p>
<a name="building-qt-as-a-shared-library"></a>
<h3>Building Qt as a Shared Library</h3>
<p>We assume that you already have installed Qt as a shared library, which is the default when installing Qt, in the <tt>C:\path\to\Qt</tt> directory. For more information on how to build Qt, see the <a href="installation.html">Installation</a> documentation.</p>
<a name="linking-the-application-to-qt-as-a-shared-library"></a>
<h3>Linking the Application to Qt as a Shared Library</h3>
<p>After ensuring that Qt is built as a shared library, we can build the Plug &amp; Paint application. First, we must go into the directory that contains the application:</p>
<pre class="cpp">cd examples\tools\plugandpaint</pre>
<p>Now run <tt>qmake</tt> to create a new makefile for the application, and do a clean build to create the dynamically linked executable:</p>
<pre class="cpp">nmake clean
qmake <span class="operator">-</span>config release
nmake</pre>
<p>This builds the core application, the following will build the plugins:</p>
<pre class="cpp">cd <span class="operator">.</span><span class="operator">.</span>\plugandpaintplugins
nmake clean
qmake <span class="operator">-</span>config release
nmake</pre>
<p>If everything compiled and linked without any errors, we will get a <tt>plugandpaint.exe</tt> executable and the <tt>pnp_basictools.dll</tt> and <tt>pnp_extrafilters.dll</tt> plugin files.</p>
<a name="creating-the-application-package"></a>
<h3>Creating the Application Package</h3>
<p>To deploy the application, we must make sure that we copy the relevant Qt DLL (corresponding to the Qt modules used in the application) and the windows platform plugin as well as the executable to the same directory in the <tt>release</tt> subdirectory.</p>
<p>In contrast to user plugins, Qt plugins have to be put into subdirectories matching the plugin type. As we want to deploy the windows platform plugin it has to be put into a &quot;platforms&quot; subdirectory. Additional information about user and Qt plugins will be covered later.</p>
<p>Qt relies on the <a href="http://site.icu-project.org/">ICU</a> library for unicode support. Therefore, you must include the ICU DLLs that are located in the <tt>bin</tt> directory of your Qt installation if Qt was configured to use ICU. The Qt version bundled in the Qt5 package uses ICU, so deployment is needed there. The ICU DLLs are version dependent and have to match the ones your Qt version was linked against.</p>
<p>If you are using <a href="http://code.google.com/p/angleproject/">ANGLE</a> (the default) then you additionally need to include both libEGL.dll and libGLESv2.dll from Qt's 'lib' directory as well as the HLSL compiler from DirectX. The HLSL compiler library is called d3dcompiler_XX.dll where XX is the version number that ANGLE (libGLESv2) was linked against.</p>
<p>Remember that if your application depends on compiler specific libraries, these must be redistributed along with your application. You can check which libraries your application is linking against by using the <tt>depends</tt> tool. For more information, see the <a href="#application-dependencies">Application Dependencies</a> section.</p>
<p>We'll cover the plugins shortly, but first we'll check that the application will work in a deployed environment: Either copy the executable and the Qt DLLs to a machine that doesn't have Qt or any Qt applications installed, or if you want to test on the build machine, ensure that the machine doesn't have Qt in its environment.</p>
<p>If the application starts without any problems, then we have successfully made a dynamically linked version of the Plug &amp; Paint application. But the application's functionality will still be missing since we have not yet deployed the associated plugins.</p>
<p>Plugins work differently to normal DLLs, so we can't just copy them into the same directory as our application's executable as we did with the Qt DLLs. When looking for plugins, the application searches in a <tt>plugins</tt> subdirectory inside the directory of the application executable.</p>
<p>So to make the plugins available to our application, we have to create the <tt>plugins</tt> subdirectory and copy over the relevant DLLs:</p>
<pre class="cpp">plugins\pnp_basictools<span class="operator">.</span>dll
plugins\pnp_extrafilters<span class="operator">.</span>dll</pre>
<p>An archive distributing all the Qt DLLs and application specific plugins required to run the Plug &amp; Paint application, would have to include the following files:</p>
<table class="generic" width="100%">
 <thead><tr class="qt-style"><th >Component</th><th  colspan="2" rowspan=" 1">File Name</th></tr></thead>
<tr valign="top" class="odd"><td >The executable</td><td  colspan="2" rowspan=" 1"><tt>plugandpaint.exe</tt></td></tr>
<tr valign="top" class="even"><td >The Basic Tools plugin</td><td  colspan="2" rowspan=" 1"><tt>plugins\pnp_basictools.dll</tt></td></tr>
<tr valign="top" class="odd"><td >The ExtraFilters plugin</td><td  colspan="2" rowspan=" 1"><tt>plugins\pnp_extrafilters.dll</tt></td></tr>
<tr valign="top" class="even"><td >The Qt Windows platform plugin</td><td  colspan="2" rowspan=" 1"><tt>platforms\qwindows.dll</tt></td></tr>
<tr valign="top" class="odd"><td >The Qt Core module</td><td  colspan="2" rowspan=" 1"><tt>Qt5Core.dll</tt></td></tr>
<tr valign="top" class="even"><td >The Qt GUI module</td><td  colspan="2" rowspan=" 1"><tt>Qt5Gui.dll</tt></td></tr>
<tr valign="top" class="odd"><td >The Qt Widgets module</td><td  colspan="2" rowspan=" 1"><tt>Qt5Widgets.dll</tt></td></tr>
</table>
<p>In addition, the archive must contain the following compiler specific libraries depending on your version of Visual Studio:</p>
<table class="generic" width="100%">
 <thead><tr class="qt-style"><th ></th><th >VC++ 8.0 (2005)</th><th >VC++ 9.0 (2008)</th><th >VC++ 10.0 (2010)</th></tr></thead>
<tr valign="top" class="odd"><td >The C run-time</td><td ><tt>msvcr80.dll</tt></td><td ><tt>msvcr90.dll</tt></td><td ><tt>msvcr100.dll</tt></td></tr>
<tr valign="top" class="even"><td >The C++ run-time</td><td ><tt>msvcp80.dll</tt></td><td ><tt>msvcp90.dll</tt></td><td ><tt>msvcp100.dll</tt></td></tr>
</table>
<p>If ICU was used, the archive must contain:</p>
<table class="generic" width="100%">
 <thead><tr class="qt-style"><th  colspan="3">File Name</th></tr></thead>
<tr valign="top" class="odd"><td >icudtXX.dll</td><td >icuinXX.dll</td><td >icuucXX.dll</td></tr>
</table>
<p>Finally, if ANGLE was used, then the archive must additionally contain:</p>
<table class="generic" width="100%">
 <thead><tr class="qt-style"><th  colspan="3">File Name</th></tr></thead>
<tr valign="top" class="odd"><td >libEGL.dll</td><td >libGLESv2.dll</td><td >d3dcompiler_XX.dll</td></tr>
</table>
<p>To verify that the application now can be successfully deployed, you can extract this archive on a machine without Qt and without any compiler installed, and try to run it.</p>
<p>An alternative to putting the plugins in the plugins subdirectory is to add a custom search path when you start your application using QApplication::addLibraryPath() or QApplication::setLibraryPaths().</p>
<pre class="cpp">qApp<span class="operator">-</span><span class="operator">&gt;</span>addLibraryPath(<span class="string">&quot;C:\some\other\path&quot;</span>);</pre>
<p>One benefit of using plugins is that they can easily be made available to a whole family of applications.</p>
<p>It's often most convenient to add the path in the application's <tt>main()</tt> function, right after the QApplication object is created. Once the path is added, the application will search it for plugins, in addition to looking in the <tt>plugins</tt> subdirectory in the application's own directory. Any number of additional paths can be added.</p>
<a name="manifest-files"></a>
<h3>Manifest files</h3>
<p>When deploying an application compiled with Visual Studio 2005 onwards, there are some additional steps to be taken.</p>
<p>First, we need to copy the manifest file created when linking the application. This manifest file contains information about the application's dependencies on side-by-side assemblies, such as the runtime libraries.</p>
<p>The manifest file needs to be copied into the <b>same</b> folder as the application executable. You do not need to copy the manifest files for shared libraries (DLLs), since they are not used.</p>
<p>If the shared library has dependencies that are different from the application using it, the manifest file needs to be embedded into the DLL binary. Since Qt 4.1&#x2e;3, the follwoing <tt>CONFIG</tt> options are available for embedding manifests:</p>
<pre class="cpp">embed_manifest_dll
embed_manifest_exe</pre>
<p>To use the options, add</p>
<pre class="cpp">CONFIG += embed_manifest_exe</pre>
<p>to your .pro file. The <tt>embed_manifest_dll</tt> option is enabled by default. The <tt>embed_manifest_exe</tt> option is NOT enabled by default.</p>
<p>You can find more information about manifest files and side-by-side assemblies at the <a href="http://msdn.microsoft.com/en-us/library/aa376307.aspx">MSDN website</a>.</p>
<p>The correct way to include the runtime libraries with your application is to ensure that they are installed on the end-user's system.</p>
<p>To install the runtime libraries on the end-user's system, you need to include the appropriate Visual C++ Redistributable Package (VCRedist) executable with your application and ensure that it is executed when the user installs your application.</p>
<p>For example, on an 32-bit x86-based system, you would include the <a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE">vcredist_x86.exe</a> executable. The <a href="http://www.microsoft.com/downloads/details.aspx?familyid=526BF4A7-44E6-4A91-B328-A4594ADB70E5">vcredist_IA64.exe</a> and <a href="http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B">vcredist_x64.exe</a> executables provide the appropriate libraries for the IA64 and 64-bit x86 architectures, respectively.</p>
<p><b>Note: </b>The application you ship must be compiled with exactly the same compiler version against the same C runtime version. This prevents deploying errors caused by different versions of the C runtime libraries.</p><a name="manual-installations-with-visual-studio-2008-and-2010"></a>
<h3>Manual installations with Visual Studio 2008 and 2010</h3>
<p>As well as the above details for VS 2005 and onwards, Visual Studio 2008/2010 applications may have problems when deploying manually, say to a USB stick.</p>
<p>The recommended procedure is to configure Qt with the <tt>-plugin-manifests</tt> option using the 'configure' tool. Then follow the <a href="http://msdn.microsoft.com/en-us/library/ms235291(VS.80).aspx">guidelines</a> for manually deploying private assemblies.</p>
<p>In brief the steps are</p>
<ol class="1">
<li>create a folder structure on the development computer that will match the target USB stick directory structure, for example '\app' and for your dlls, '\app\lib'.</li>
<li>on the development computer, from the appropriate 'redist' folder copy over Microsoft.VC80.CRT and Microsoft.VC80.MFC to the directories '\app' and '\app\lib' on the development PC.</li>
<li>xcopy the \app folder to the target USB stick.</li>
</ol>
<p>Your application should now run. Also be aware that even with a service pack installed the Windows DLLs that are linked to will be the defaults. See the information on <a href="http://msdn.microsoft.com/en-us/library/cc664727.aspx">how to select the appropriate target DLLs</a>.</p>
<a name="application-dependencies"></a>
<h2>Application Dependencies</h2>
<a name="additional-libraries"></a>
<h3>Additional Libraries</h3>
<p>Depending on configuration, compiler specific libraries must be redistributed along with your application.</p>
<p>For example, if Qt is built using <a href="http://code.google.com/p/angleproject/">ANGLE</a>, its shared libraries and the required shared libraries of the <a href="http://msdn.microsoft.com/en-us/directx/default.aspx">Direct X SDK</a> need to be shipped as well.</p>
<p>You can check which libraries your application is linking against by using the <a href="http://www.dependencywalker.com/">Dependency Walker</a> tool. All you need to do is to run it like this:</p>
<pre class="cpp">depends <span class="operator">&lt;</span>application executable<span class="operator">&gt;</span></pre>
<p>This will provide a list of the libraries that your application depends on and other information.</p>
<p class="centerAlign"><img src="images/deployment-windows-depends.png" alt="" /></p><p>When looking at the release build of the Plug &amp; Paint executable (<tt>plugandpaint.exe</tt>) with the <tt>depends</tt> tool, the tool lists the following immediate dependencies to non-system libraries:</p>
<table class="generic" width="100%">
 <thead><tr class="qt-style"><th >Qt</th><th >VC++ 8.0 (2005)</th><th >VC++ 9.0 (2008)</th><th >VC++ 10.0 (2010)</th><th ><a href="http://www.mingw.org/">MinGW</a></th></tr></thead>
<tr valign="top" class="odd"><td ><ul>
<li>QT5CORE.DLL - The QtCore runtime</li>
<li>QT5GUI.DLL - The QtGui runtime</li>
<li>QT5WIDGETS.DLL - The QtWidgets runtime</li>
</ul>
</td><td ><ul>
<li>MSVCR80.DLL - The C runtime</li>
<li>MSVCP80.DLL - The C++ runtime</li>
</ul>
</td><td ><ul>
<li>MSVCR90.DLL - The C runtime</li>
<li>MSVCP90.DLL - The C++ runtime</li>
</ul>
</td><td ><ul>
<li>MSVCR100.DLL - The C runtime</li>
<li>MSVCP100.DLL - The C++ runtime</li>
</ul>
</td><td ><ul>
<li>MINGWM10.DLL - The <a href="http://www.mingw.org/">MinGW</a> run-time</li>
<li>LIBGCC_S_DW2-1.DLL</li>
<li>LIBSTDC++-6.dll</li>
</ul>
</td></tr>
</table>
<p>When looking at the plugin DLLs the exact same dependencies are listed.</p>
<a name="qt-plugins"></a>
<h3>Qt Plugins</h3>
<p>Your application may also depend on one or more Qt plugins, such as the print support plugin, the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any Qt plugins that you need with your application, and note that each type of plugin should be located within a specific subdirectory (such as <tt>printsupport</tt>, <tt>imageformats</tt> or <tt>sqldrivers</tt>) within your distribution directory, as described below.</p>
<p><b>Note: </b>If you are deploying an application that uses QtWebKit to display HTML pages from the World Wide Web, you should include all text codec plugins to support as many HTML encodings possible.</p><p>The search path for Qt plugins is hard-coded into the QtCore library. By default, the plugins subdirectory of the Qt installation is the first plugin search path. However, pre-determined paths like the default one have certain disadvantages. For example, they may not exist on the target machine. For that reason, you need to examine various alternatives to make sure that the Qt plugins are found:</p>
<ul>
<li><a href="qt-conf.html">Using <tt>qt.conf</tt></a>. This approach is the recommended if you have executables in different places sharing the same plugins.</li>
<li>Using QApplication::addLibraryPath() or QApplication::setLibraryPaths(). This approach is recommended if you only have one executable that will use the plugin.</li>
<li>Using a third party installation utility to change the hard-coded paths in the QtCore library.</li>
</ul>
<p>If you add a custom path using QApplication::addLibraryPath it could look like this:</p>
<pre class="cpp">qApp<span class="operator">-</span><span class="operator">&gt;</span>addLibraryPath(<span class="string">&quot;C:/customPath/plugins&quot;</span>);</pre>
<p>Then qApp-&gt;libraryPaths() would return something like this:</p>
<p>&quot;C:/customPath/plugins&quot; &quot;C:/Qt/5.1&#x2e;1/plugins&quot; &quot;E:/myApplication/directory/&quot;</p>
<p>The executable will look for the plugins in these directories and the same order as the QStringList returned by qApp-&gt;libraryPaths(). The newly added path is prepended to the qApp-&gt;libraryPaths() which means that it will be searched through first. However, if you use qApp-&gt;setLibraryPaths(), you will be able to determine which paths and in which order they will be searched.</p>
<p>The How to Create Qt Plugins document outlines the issues you need to pay attention to when building and deploying plugins for Qt applications.</p>
<a name="related-third-party-resources"></a>
<h2>Related Third Party Resources</h2>
<ul>
<li><a href="http://silmor.de/29">Cross compiling Qt/Win Apps on Linux</a> covers the process of cross-compiling Windows applications on Linux.</li>
<li><a href="http://divided-mind.blogspot.com/2007/09/cross-compiling-qt4win-on-linux.html">Cross-compiling Qt4/Win on Linux</a> provides another Linux-to-Windows cross-compilation guide.</li>
</ul>
</div>
<!-- @@@deployment-windows.html -->
<p class="naviNextPrevious footerNavi">
</p>
</div>
</div>
</div>
<div class="footer">
    <p>
      <acronym title="Copyright">&copy;</acronym> 2013 Digia Plc and/or its
      subsidiaries. Documentation contributions included herein are the copyrights of
      their respective owners.</p>
    <br />
    <p>
      The documentation provided herein is licensed under the terms of the
      <a href="http://www.gnu.org/licenses/fdl.html">GNU Free Documentation
      License version 1.3</a> as published by the Free Software Foundation.</p>
    <p>
      Documentation sources may be obtained from <a href="http://www.qt-project.org">
      www.qt-project.org</a>.</p>
    <br />
    <p>
      Digia, Qt and their respective logos are trademarks of Digia Plc 
      in Finland and/or other countries worldwide. All other trademarks are property
      of their respective owners. <a title="Privacy Policy"
      href="http://en.gitorious.org/privacy_policy/">Privacy Policy</a></p>
</div>
</body>
</html>