QtWebEngine deployment issue

Bardfast · 20 Mar 2024, 15:45

I’m trying to deploy - to a Linux (Ubuntu) machine – a C++ application that makes use of QtWebEngineView, but am unable to get it to run. To simplify the issue I’ve written the following trivial sample application to use as a test.

#include <iostream>
#include <iomanip>
#include <cstdlib>

#include <QApplication>
#include <QWebEngineView>
#include <QLibraryInfo>

//------------------------------------------------------------------------------
int main (int argc, char** argv)
{
	static const char* LINE = "\n-----------------------------------------------------";
	const char* webPath = getenv ("QTWEBENGINEPROCESS_PATH");
	std::cout
		<< LINE
		<< "\nQLibraryInfo::LibraryExecutablesPath = " << std::quoted (QLibraryInfo::location (QLibraryInfo::LibraryExecutablesPath).toStdString())
		<< "\nQLibraryInfo::DataPath = " << std::quoted (QLibraryInfo::location (QLibraryInfo::DataPath).toStdString())
		<< "\nQLibraryInfo::TranslationsPath = " << std::quoted (QLibraryInfo::location (QLibraryInfo::TranslationsPath).toStdString())
		<< "\nQTWEBENGINEPROCESS_PATH = " << std::quoted (webPath ? webPath : "")
		<< LINE
		<< std::endl
		<< std::flush;

	QApplication app (argc, argv);
	QWebEngineView view;
	view.load (QUrl (argc == 2 ? argv[1] : "http://127.0.0.1:9099/dok"));
	view.show();

	return app.exec();
}

This runs perfectly well in my development (build) environment, but fails on the deployment machine, showing the following output …

$ ./TestWebEngine

-----------------------------------------------------
QLibraryInfo::LibraryExecutablesPath = "/home/fred/vms/bin/qt/libexec"
QLibraryInfo::DataPath = "/home/fred/vms/bin/qt"
QLibraryInfo::TranslationsPath = "/home/fred/vms/bin/qt/translations"
QTWEBENGINEPROCESS_PATH = "/home/fred/vms/bin/qt/libexec/"
-----------------------------------------------------
QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
LaunchProcess: failed to execvp:
/home/fred/vms/bin/qt/libexec/
LaunchProcess: failed to execvp:
/home/fred/vms/bin/qt/libexec/
Trace/breakpoint trap (core dumped)

All of the folders above exist and contain the same files as were found on the build machine.
Running glxinfo indicates that GLX is ‘enabled’.
Running ldd on the QtWebEngineProcess executable confirms that there are no missing libraries.
Chrome is installed and working on the deployment machine.

What steps can I take to resolve this issue ? Any suggestions would be most welcome.

Bardfast · 21 Mar 2024, 13:34

@JonB Success!! Thanks again – your contribution was critical.

I finally realized that the environment variable QTWEBENGINEPROCESS_PATH should have also included the process name. It was mistakenly set to …

/home/fred/vms/bin/qt/libexec/

It should have been …

/home/fred/vms/bin/qt/libexec/QtWebEngineProcess

JonB · 21 Mar 2024, 11:12

@Bardfast said in QtWebEngine deployment issue:

QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled

I would concentrate on this line. QtWebEngine may be a "red herring" in itself, except that it calls for libraries. If you Google for that error message there are quite a few hits to see if any relate to you. I note that https://forum.qt.io/topic/69227/linux-deployment-qxcbintegration-cannot-create-platform-opengl-context-neither-glx-nor-egl-are-enabled/11 said it was solved by addressing plugins for deployment, is that relevant to your situation?

Bardfast · 21 Mar 2024, 12:12

@JonB Thanks for your suggestion. Yes, I have been focused on that particular error message, but nothing that I’ve found so far seems to have any bearing on my issue.

Something that I didn’t mention before is that I had previously managed to successfully deployed and run my full GUI application on that machine, but at the point where the code actions a web connection (usingQtWebEngineView) the process does tha same core dump.

It was for this reason that I created the simplified test app that only attempts to connect to the same website using QtWebEngineView.

The issue does seem to be associated with QtWebEngineView specifically.

For more detail, I ran the test app again, but with QT_DEBUG_PLUGINS = 1 and I get this console display …

$ ./TestWebEngine

-----------------------------------------------------
QLibraryInfo::LibraryExecutablesPath = "/home/fred/vms/bin/qt/libexec"
QLibraryInfo::DataPath = "/home/fred/vms/bin/qt"
QLibraryInfo::TranslationsPath = "/home/fred/vms/bin/qt/translations"
QTWEBENGINEPROCESS_PATH = "/home/fred/vms/bin/qt/libexec/"
QT_DEBUG_PLUGINS = "1"
-----------------------------------------------------
QFactoryLoader::QFactoryLoader() checking directory path "/home/fred/vms/bin/qt/plugins/platforms" ...
**bolded text**
...
etc
...

Got keys from plugin meta data ("xcb_egl")
QFactoryLoader::QFactoryLoader() looking at "/home/fred/vms/bin/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so"
Found metadata in lib /home/fred/vms/bin/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.Xcb.QXcbGlIntegrationFactoryInterface.5.5",
    "MetaData": {
        "Keys": [
            "xcb_glx"
        ]
    },
    "archreq": 0,
    "className": "QXcbGlxIntegrationPlugin",
    "debug": false,
    "version": 331520
}


Got keys from plugin meta data ("xcb_glx")
QFactoryLoader::QFactoryLoader() checking directory path "/home/fred/vms/bin/xcbglintegrations" ...
loaded library "/home/fred/vms/bin/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so"
QFactoryLoader::QFactoryLoader() checking directory path "/home/fred/vms/bin/qt/plugins/styles" ...
QFactoryLoader::QFactoryLoader() checking directory path "/home/fred/vms/bin/styles" ...
LaunchProcess: failed to execvp:
/home/fred/vms/bin/qt/libexec/
LaunchProcess: failed to execvp:
/home/fred/vms/bin/qt/libexec/
Trace/breakpoint trap (core dumped)

JonB · 21 Mar 2024, 13:16

@Bardfast said in QtWebEngine deployment issue:

LaunchProcess: failed to execvp:
/home/fred/vms/bin/qt/libexec/
LaunchProcess: failed to execvp:
/home/fred/vms/bin/qt/libexec/

I will just say: Linux execvp() takes path to an executable file to execute. /home/fred/vms/bin/qt/libexec/ is clearly a directory, so assuming it has called it with that it's not surprising you get failed to execvp. I know no more than this. What you are supposed to do with this information I do not know, but it looks to me like it's trying to execute the wrong thing, e.g. it failed to find some executable file to append to that path.

Bardfast · 21 Mar 2024, 13:32

@JonB said in QtWebEngine deployment issue:

Thanks again. That’s an interesting observation.

As an experiment ...

I moved the required executable QtWebEngineProcess out of the /home/fred/vms/bin/qt/libexec/ folder to an entirely different place – effectively ‘deleting’ it – and got exactly the same result as before.

Yet if I do that on my own development machine (where it does successfully run) I get a different but reasonable error. Specifically …

Could not find QtWebEngineProcess
Aborted (core dumped)

I also found another post on the internet where they were also having a different problem launching QtWebEngineProcess, and their trace was as you would expect ...

LaunchProcess: failed to execvp:
/opt/Stremio/libexec/QtWebEngineProcess

Then – as a bizarre test – I renamed (hid) the /home/fred/vms/bin/qt/libexec/ folder and copied the QtWebEngineProcess binary up one level and renamed it to libexec – so that /home/fred/vms/bin/qt/libexec would actually represent an alias for the QtWebEngineProcess binary. The result was surprising …

Could not find QtWebEngineProcess
Aborted (core dumped)

So in summary, it looks like you are correct. For some reason the Qt ‘execvp’ method is failing to execute properly.

Bardfast · 21 Mar 2024, 13:34

@JonB Success!! Thanks again – your contribution was critical.

I finally realized that the environment variable QTWEBENGINEPROCESS_PATH should have also included the process name. It was mistakenly set to …

/home/fred/vms/bin/qt/libexec/

It should have been …

/home/fred/vms/bin/qt/libexec/QtWebEngineProcess

JonB · wrote on 21 Mar 2024, 13:34

@Bardfast Ah ha! That was indeed the clue then :) Always worth looking at error message in detail