Deploying an Application on X11 Platforms

Creating the Application Package

There is no standard package management on Unix, so the method we present below is a generic solution. See the documentation for your target system for information on how to create a package.

To deploy the application, we must make sure that we copy the relevant Qt libraries (corresponding to the Qt modules used in the application) as well as the executable to the same directory. Remember that if your application depends on compiler specific libraries, these must also be redistributed along with your application. For more information, see the Application Dependencies section.

We'll cover the plugins shortly, but the main issue with shared libraries is that you must ensure that the dynamic linker will find the Qt libraries. Unless told otherwise, the dynamic linker doesn't search the directory where your application resides. There are many ways to solve this:

• You can install the Qt libraries in one of the system library paths (e.g. /usr/lib on most systems).
• You can pass a predetermined path to the -rpath command-line option when linking the application. This will tell the dynamic linker to look in this directory when starting your application.
• You can write a startup script for your application, where you modify the dynamic linker configuration (e.g., adding your application's directory to the LD_LIBRARY_PATH environment variable.

  Note: If your application will be running with "Set user ID on execution," and if it will be owned by root, then LD_LIBRARY_PATH will be ignored on some platforms. In this case, use of the LD_LIBRARY_PATH approach is not an option).

The disadvantage of the first approach is that the user must have super user privileges. The disadvantage of the second approach is that the user may not have privileges to install into the predetemined path. In either case, the users don't have the option of installing to their home directory. We recommend using the third approach since it is the most flexible. For example, a plugandpaint.sh script will look like this:

 #!/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 "$@"

By running this script instead of the executable, you are sure that the Qt libraries will be found by the dynamic linker. Note that you only have to rename the script to use it with other applications.

When looking for plugins, the application searches in a plugins subdirectory inside the directory of the application executable. Either you have to manually copy the plugins into the plugins directory, or you can set the DESTDIR in the plugins' project files:

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

An archive distributing all the Qt libraries, and all the plugins, required to run the Plug & Paint application, would have to include the following files:

On most systems, the extension for shared libraries is .so. A notable exception is HP-UX, which uses .sl.

Remember that if your application depends on compiler specific libraries, these must still be redistributed along with your application. For more information, see the Application Dependencies section.

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, i.e. run the plugandpaint.sh script.

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().

 qApp->addLibraryPath("/some/other/path");

 ldd ./application