How can I configure platform plugin search path when building Qt5?

[JW16]

I am building Qt 5.15 from source for Red Hat 7, Red Hat 8, and Ubuntu 18 platforms to use for my application. I am able to build Qt and build my application using it, and deploy all libraries and plugins. My issue is that when I attempt to launch my application on Ubuntu 18, I encounter the console message about being unable to find the Qt xcb platform plugin (libqxcb.so). It exists in the same location for the builds on all three platforms (approot/lib/platforms). For the Red Hat builds, Qt is able to locate the plugin fine and works with no issues. On Ubuntu 18, I have to move the platforms folder containing the plugin to approot/bin/ instead, and then Qt will be able to locate the plugin and launch my application.

My question is two part:

1. why do Qt look for the plugin in a different location on Ubuntu?
2. can I configure Qt when building it from source to look at a different path? Ideally I want the deployment of my application to be identical across platforms.

Thanks

[Christian Ehrlicher]

This has nothing to do with the search path but with the dependencies of the xcb plugin. Check with ldd to see which x11 lib is missing on this system.

[kkoehne]

@Christian-Ehrlicher well, @JW16 says libxcb plugin is loaded if moved to the 'right' folder. So apparently, it's dependencies are satisfied?

@JW16 , I don't know the answer to your problem, but here are some hints for you to further investigate:

• Have you used any 'deployment tool' to create your structure? Are you using a qt.conf file besides your executable (so approot/bin/qt.conf)?
• Launch your app in an environment where QT_DEBUG_PLUGINS environment variable is set. Which locations are listed ?
• Run qtpaths -query QT_INSTALL_PLUGINS. Are the same paths reported?

[JW16]

@Christian-Ehrlicher You are misunderstanding my question. All dependencies for the plugin are satisfied. Qt is looking for the plugin in a different path but only on my Ubuntu system. I am asking if I can configure Qt to look in the same location as it is on Red Hat systems when building Qt on Ubuntu.

[JoeCFD]

@JW16 you can also use QT_PLUGIN_PATH to set plugin path. In this way, you may not care about the differences of Ubuntu and Red Hat.

[JW16]

@JoeCFD Right, but I want my application to work out of the box without the user having to set paths in their environment. So I want to know why Qt defaults to a different location on Ubuntu compared to RH, and whether I can control that default location when configuring/building Qt from source.

[JoeCFD]

@JW16 I do not know why Qt made the plugin path differently in RH. You can set the env variable in your install script somehow. Users do not need to know this. It is not their job either.

[JW16]

@kkoehne Yes you are correct, all package dependencies are satisfied.

No, I am not using a deployment tool nor am I using a qt.conf file.

Setting QT_DEBUG_PLUGINS=1 and launching my application reports that QFactoryLoader is looking in approot/bin/ for the platforms dir. The next message is the one about failing to find the plugin.

qtpaths -query is not recognized option for qtpaths. I am using Qt 5.15. Is there some other options you meant? I am not seeing an obvious one looking at the command line help for qtpaths.

[jsulm]

@JW16 Maybe https://doc.qt.io/qt-6/qt-conf.html can help?

[kkoehne]

@JW16 said in How can I configure platform plugin search path when building Qt5?:

qtpaths -query is not recognized option for qtpaths. I am using Qt 5.15. Is there some other options you meant? I am not seeing an obvious one looking at the command line help for qtpaths.

Right, for Qt 5, you have to run qmake -query QT_INSTALL_PLUGINS

Can you verify:

• The output of QCoreApplication::libraryPaths()
• The output of QLibraryInfo::location(QLibraryInfo::PluginsPath)

on both Red Hat and Ubuntu?

[JW16]

@kkoehne

qmake -query QT_INSTALL_PLUGINS just returns the path to the plugins folder in my Qt build (~/qt5root/plugins). This is true for both Ubuntu and Red Hat.

Red Hat QCoreApplication::libraryPaths() :

• /usr/lib64/kde4/plugins
• /usr/lib/kde4/plugins
• ~/qt5root/plugins
• ~/approot/bin

Red Hat QLibraryInfo::location(PluginsPath):

• ~/qt5root/plugins

Ubuntu QCoreApplication::libraryPaths():

• ~/approot/bin

Ubuntu QLibraryInfo::location(PluginsPath):

• ~/approot/plugins

So it doesn't seem that my Red Hat builds are looking in ~/approot/lib at all and are instead finding the plugins in my Qt5 build directory? Any idea why these paths are different? FWIW, these are the outputs from my application immediately after creating my QApplication object and calling the above functions.

[JoeCFD]

@JW16 Run
env | grep Q
and
echo $LD_LIBRARY_PATH /* pay attention to the order as well */
to see if any Qt env variable or path is set differently in RH and Ubuntu.

[JW16]

@JoeCFD Nothing obvious. No Qt paths in LD_LIBRARY_PATH. On both systems, the QTDIR variable points at the appropriate qt5 build root. On Ubuntu, I additionally see QT_ACCESSIBILITY=1 and QT_IM_MODULE=xim. On Red Hat, there is no QT_ACCESSIBILITY variable and QT_IM_MODULE=ibus instead.

[hskoglund]

To regain some control of where Qt looks for plugins, why not try a addLibraryPath(), say like this:

int main(int argc, char *argv[])
{
    QCoreApplication::addLibraryPath("~/approot/lib");
    QApplication a(argc,argv);
...

(note: the call has be to made before the QApplication ctor)

[JW16]

@hskoglund Thanks for the suggestion. I am trying to understand what causes Qt to have differing paths for different systems in the first place. It feel like something that should be controllable when building Qt from source as I have.

[hskoglund]

If you're anyway building from source, one way to avoid "plugin hell" is to try building a static version of Qt.

When you compile and link with a static version, all needed .so files and plugins are linked together into one giant executable.
(I have a static version of Qt 6 and when building a QWidgets app on Ubuntu 22.04 the resulting executable is about 26 Mb, not so bad.)

Note that building a static version is more complicated than building s dynamic version (more pain at start but less pain when deploying).

[JonB]

@JW16
Since you are compiling Qt yourself, are you already compiling it for Debug or are you prepared to do so? Then you could put a breakpoint on QCoreApplication::libraryPaths() or QLibraryInfo::location() etc. and step through seeing where each platform gets its information from. I know this is a "do it yourself manually" solution, but if it's important to you to get the right answer give it a go and see how long it's taking you? It's what I would do.

[kkoehne]

@JW16 said in How can I configure platform plugin search path when building Qt5?:

So it doesn't seem that my Red Hat builds are looking in ~/approot/lib at all and are instead finding the plugins in my Qt5 build directory?

Looks like it, yes. You could verify by running your app with QT_DEBUG_PLUGINS=1 on Red Hat.

Any idea why these paths are different?

Qt provides different hooks to expand the list of paths. As others have already noted, that includes calling QCoreApplication::setLibraryPaths(), QCoreApplication::addLibraryPath(), having a qt.conf file aside your executable, setting the QT_PLUGIN_PATH environment variable.

So, let's look at the list for Red Hat:

/usr/lib64/kde4/plugins
/usr/lib/kde4/plugins

I guess that your runtime environment defines these in the QT_PLUGIN_PATH environment variable (see also https://bugzilla.redhat.com/show_bug.cgi?id=468330).

~/qt5root/plugins

Is the return value of QLibraryInfo::location(PluginsPath), so where Qt was installed to.

~/approot/bin

This is the application directory (where the executable is found), which is also added.

Now, Ubuntu. It doesn't define any QT_PLUGIN_PATH, and ~/approot/pluginsdoesn't exist (I assume), so it's left with the executable directory.

But why does QLibraryInfo::location(PluginsPath) return a location that doesn't exist? If you don't really have any qt.conf file anywhere (either on disk or in the resources under :/qt/etc/qt.conf, I suspect there must be something different at Qt compile time :/