Case study:

Solving conflicting libraries

The problem:

A customer had the issue of conflicting libraries when their product was running at client side. The application terminated with this valuable output message:

“Cannot mix incompatible Qt library (version 0x40805) with this library (version 0x40804)”

The customer therefore wanted to use Breeze to identify the solution.

The solution:

Initially, it sounds as though the client has conflicting libraries. One reason for this might be down to having a valid installation of libraries on the system (as happens with Qt when KDE is installed) and another copy with a different version having been shipped with the actual program. Such a library could then be introduced by LD_LIBRARY_PATH, which enforces the library loader to use these libraries in preference.

To see if this is the case using Breeze, go to the Timeline View and select one of the latest applications or the one that failed to run. Right click it, then -> System Environment. Copy and paste the information to a text editor.

In the text editor, if we search for “Qt” we can see [installation path]/Tools/Qt/Linux64/lib within the environment variable: LD_LIBRARY_PATH. We also see other Qt related paths which point to the native installation:

QTDIR=/usr/lib64/qt-3.3
QTINC=/usr/lib64/qt-3.3/include
QTLIB=/usr/lib64/qt-3.3/lib
QT_PLUGIN_PATH=~/.kde/lib64/kde4/plugins/:/usr/lib64/kde4/plugins/

One solution to the problem might be to unset the LD_LIBRARY_PATH if this is possible. Therefore we need to find out which application introduced the LD_LIBRARY_PATH.

To identify which application introduced the environment, in Breeze we switch to the Node View and step closer to the root node of the run.

First, inspect the environment of the initial executable; if there are no Qt libraries in LD_LIBRARY_PATH step further towards the application which has it set. As soon as this is identified we know that the parent process set the LD_LIBRARY_PATH, and it can be inspected and modified manually. This might remove the library mismatch.

It may be that the shipped application does not work with the natively installed library. In this case the application would either need a rebuild or we need to remove the references to the native paths.

Again, this can be done by inspecting the System Environment of the main process that failed to load. We search case insensitive for “qt” and along with the LD_LIBRARY_PATH we can also identify a QT_PLUGIN_PATH, which is the native installation path.

The result:

In the main calling script, it is now possible to unset QT_PLUGIN_PATH or modify it to the shipped distribution of Qt. This solved the problem for the customer.