[Interest] Qt 5.12 official build on Ubuntu 14.04

Thiago Macieira thiago.macieira at intel.com
Tue Mar 12 02:01:37 CET 2019

On Monday, 11 March 2019 03:56:59 PDT René J.V. Bertin wrote:
> One hurdle: my distribution uses dbus 1.6.x which lacks at least 1 function
> required by libQt5Dbus. I don't really want to risk rolling my own upgrade
> for that. So instead I installed dbus 1.12.12 into my usual /opt/local
> parallel prefix with a suffix on the binaries and configured to use the
> same runtime resources as the host dbus. That seems to work just fine,
> despite the fact that it communicates through an older dbus daemon and with
> other clients that will use the older libdbus library.

That shouldn't be a problem.

> I do observe something very curious and surprising. All my KF5 applications
> from /opt/local run just fine against this Qt 5.12 install, and a few of
> the simpler "pure Qt" applications do too (like qdbusviewer and even
> linguist). But most fail very quickly with this error:
> %> /opt/Qt/5/5.12.1/thisQt.sh /opt/local/libexec/qt5/bin/assistant
> This application failed to start because it could not find or load the Qt
> platform plugin "xcb" in "".
> When I set QT_DEBUG_PLUGINS=1 I see that only plugins from the /opt/local
> install are being loaded, yet I set QT_PLUGIN_PATH to list the 5.12 plugin
> directory first. For good measure I added an LD_PRELOAD of the 5.12
> libQt5Core to my wrapper; makes no difference.
> The difference between these "pure Qt" and the KF5 applications is that the
> former are built via qmake, the latter via cmake. Can that explain a
> difference in rpath information set in the executables which makes the
> LD_LIBRARY_PATH trick fail in the former?

There shouldn't be anything explicitly causing this. So it must be a side 
effect or just a huge coincidence. If it's a side-effect, I imagine it's 
caused by the use of DT_RUNPATH in the ELF modules, or lack thereof. But I'm 
not convinced it's a build difference, you may be seeing a coincidence. Or, 
more likely, a *library* difference: something may be calling 
QCoreApplication::setLibraryPaths(). instead of 

Can you attach the full stderr from QT_DEBUG_PLUGINS=1 run? Can you also make 
a simple QtCore application that prints the output of 
QCoreApplication::libraryPaths() ?

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

More information about the Interest mailing list