"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 the AUT is not using Qt at all, you will see this message. So this can be caused by using the wrong edition of Squish - the AUT is a win32 app that does not use Qt at all, 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. The Qt Company has instructions for how to configure a Qt application on the various platforms supported by Qt. 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 so Froglogic can make a custom build of Squish for their AUT.

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