"Failed to find Qt module to determine its runtime libraries"

Last edited on

Symptoms

Unable to attach to AUT from Squish for Qt.

Causes

If you are using Squish for Qt, and the AUT is not using Qt at all, you will see this message. So this can be caused by using Squish/Qt on a .NET or WinForms application, for example.

It also shows up when hooking up to Qt apps that are statically linked to Qt, or that have Qt libs packaged in a non-standard way. Qt has documentation articles about how to deploy a Qt application on different platforms. When not adhering to the instructions, Squish may not be able to find the Qt libraries, and thus yield the above warning.

Resolutions

If the AUT does not use Qt, use the correct edition of Squish (Squish for Windows, instead of Squish for Qt)

If the AUT uses Qt but Squish can not find it, this requires 1 of 2 things:

  1. Customer repackages AUT using DLLs for testing in Squish.

  2. Customer purchases a support package and Froglogic supplies the sources of Squish. With that the customer will be able to build part of Squish for their setup on their own terms. See the articles below fore the respective scenarios :

    custom Qt configuration

    static linked Qt

Background

In general Squish tries to load its Qt support ("Qt wrapper") into the AUT process as early as possible. In case of PyQt applications and others this may happen before the AUT set up its library search path at runtime. In such cases it may work to adjust LD_LIBRARY_PATH (Unix) or PATH (Windows) to include the path to the Qt shared libraries used by the AUT. (Be careful to append to the LD_LIBRARY_PATH and PATH environment variables instead of overwriting their current value.)