Symptom¶
The Runner/Server Log contains the following error:
ERROR: ld.so: object 'libsquishqtpre.so' from LD_PRELOAD cannot be preloaded: ignored.
If you get this error, your application might not start up at all; or it might start but not function correctly.
Possible Explanation A¶
A common cause of the cited error can be the inability of the system loader to locate the libsquishqtpre.so in the first place. When starting an application Squish sets (or modifies) the LD_LIBRARY_PATH environment variable to include its own lib/ sub-directory. This setting might get lost if the application is made up of separate components that invoke each other in separate process spaces. By use of a shell script wrapping the real executable for example.
Solution¶
Change the application to not overwrite LD_LIBRARY_PATH but to append or prepend new values only. Here is how that is done in a shell script:
LD_LIBRARY_PATH=/opt/ourapp/lib:$LD_LIBRARY_PATHThe change above described can be considered a generally useful bug fix as completely overwriting LD_LIBRARY_PATH can easily cause interoperability problems with other software components and system installations.
Possible Explanation B¶
Often this error indicates that an incompatible mixture of 32-bit and 64-bit components is being used. For example, you might be trying to test a 64-bit application with a 32-bit version of Squish, or vice versa.
Typical Solution¶
Ensure that the version of Squish matches your application's architecture. In general, 64-bit systems are able to execute 32-bit applications. So what really counts is just the application's architecture and not the system's capabilities. The most important step to avoid problems is to ensure that when you run Squish's setup program (which you can run again, if you need to change a setting), must be pointed to the Qt libraries actually used by the application. (Keep in mind that there may be more than one set of Qt libraries on a given machine.)
If you are not sure whether the application is 32-bit or 64-bit, run the file command line utility on your AUT's executable or libraries. This will print out the necessary information.
Alternative solution¶
The error might still occur, even if the application and Squish have matching architectures, i.e., are both 32-bit or both 64-bit. This can happen if the application is making use of external executables like a Unix shell or Perl interpreter that uses a different architecture again. For example, a 32-bit application might be executed by a shell script that is using a 64-bit shell.
There is rarely any point for Squish to hook into such external components since they are not usually relevant to GUI testing. So, the easiest solution is to simply ignore them by providing the system loader with a dummy library which has the correct architecture. A ready made 32-bit version is available at libsquishqtpre.so , but it is easy to create your own:
$ cd /tmp
$ touch dummy.c
$ gcc -shared -m32 -o libsquishqtpre.so dummy.cNow the only remaining task is to move the libsquishqtpre.so library to a location that can be found by the runtime linker. The original library is in Squish's lib/ directory. The runtime linker will search a built-in list of sub-directories for alternative versions so to make it find the new one, we just have to use a suitable magic directory name. The name i686 is the usual magic name for 32-bit libraries (if this does not work for you please ask froglogic support for the name to use on your system). These are the necessary steps to move the dummy library to where it can be found and used:
$ cd SQUISHDIR/lib
$ mkdir i686
$ mv /tmp/libsquishqtpre.so i686This should satisfy the loader's needs and make the error go away.