CopperSpice Overview  1.5.2
Deploying on Windows

On Windows you will need to distribute different files depending on whether you link statically or dynamically.

Static Linking

Static builds are only partially supported and have not be fully tested. You can build the CS libraries statically, but some modules may fail to work properly. WebKit is known to fail if built statically.

To use this approach you must build and install a static version of the CopperSpice libraries.

Plugins can not be deployed using the static linking approach. You application will run, but some functionality will be disabled due to the missing plugins. If your application uses plugins, you should use the shared library approach.

Linking the Application Statically

Compile and link your application with the static CopperSpice libraries.

For information on the commands to build your application, refer to Compile & Link. When you run 'configure', add the option as shown:

./configure --disable-shared

If your application depends on compiler specific libraries, these must still be distributed along with your application. You can check which libraries your application is linking against by using a dependency tool such as Dependency Walker from Microsoft.

Shared Libraries

When deploying your application using shared libraries, the correct CopperSpice libraries must be distributed along with your application. In addition, any plugin must be included and installed on the target system in the correct folders.

Linking your Application with Shared Libraries

Refer to our sample project files for details about how to compile and link your application.

Additional Libraries

Compiler specific libraries must be redistributed along with your application. You can check which libraries your application is linking against by using a Dependency Walker tool.

Creating the Application Package

To deploy your application include all the files in your 'deploy' folder. This folder was created during the 'make install' process.

If your application depends on compiler specific libraries, these must also be distributed with your application.

Plugins work differently to normal DLLs and can not simply be copied into the same directory as the application executable. When looking for plugins, your application will search for a folder called plugins. This folder must be a subdirectory under the directory of containing your application.

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


One benefit of using plugins is they can be made available to a whole family of applications.


Your application may also depend on one or more plugins, such as the JPEG image format plugin or a SQL driver plugin. Be sure to distribute any plugins that you need with your application. Each type of plugin should be located within a specific subdirectory (such as image formats or sqldrivers) within your distribution directory.

If you are deploying an application that uses WebKit, include all text codec plugins to support as many HTML encodings possible.

The following are the various alternatives to make sure that the plugins are found by your application.

  • Path Configuration This is the recommended approach since it provides the most flexibility.
  • Using QApplication::addLibraryPath() or QApplication::setLibraryPaths().
  • Using a third party installation utility or the target system's package manager to change the hard-coded paths in the CsCore library.

The Creating Plugins document outlines the important issues when building and deploying plugins. More information about deployment, refer to Deploying Plugins.