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

[SGaist]

Hi,

Did you follow the steps for deploying an application on Linux ?

[VRHans]

As far as I can tell, yes - and found that they failed to mention several things (maybe those are obvious to others.) Such as running ldd against all of the Qt libs your first run of ldd against your executable told you to include.

It also didn't mention how you should package your Qml dependencies (or if the linux version has Qml dependencies) - I presume it does so I copied over Qml, I copied over all of the plugins in case that was the problem, and I copied over all of the platform plugins in case that was the problem.

All from the GCC 64 bin and libexec directories, because I'm building with the x64 GCC kit.

[SGaist]

Do you mean you copied system libraries ?

[VRHans]

No, only libraries found in the Qt pathing of my system.

[FireEarl]

Hi, I have got the exact same problem, also tried to build Qt with -qt-xcb configuration
(From the Qt docu: "It's possible to configure Qt with -qt-xcb, which compiles in a set of xcb helper libraries instead of trying to link against the system versions. This can help make Qt less dependent on some of the xcb helper libraries that might not be available on all distributions.")

But I still get the "QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled", with the Qt dev directory in place everything works fine, also tested it on another fresh vm with Ubuntu 15.

My Application file structure looks like this:
start.sh
Application
icudtl.dat
libicudata.so.56
libicui18n.so.56
libicuuc.so.56
libQt5Core.so.5
libQt5DBus.so.5
libQt5Gui.so.5
libQt5Network.so.5
libQt5Qml.so.5
libQt5Quick.so.5
libQt5WebChannel.so.5
libQt5WebEngine.so.5
libQt5WebEngineCore.so.5
libQt5WebEngineWidgets.so.5
libQt5Widgets.so.5
libQt5XcbQpa.so.5
QtWebEngineProcess
qtwebengine_devtools_resources.pak
qtwebengine_resources.pak
qtwebengine_resources_100p.pak
qtwebengine_resources_200p.pak
plugins\platforms\libqxcb.so
qtwebengine_locales*.pak

Shell script for starting with correct LD path
start.sh:
#!/bin/sh
SCRIPT=$(readlink -f "$0")
SCRIPTPATH=$(dirname "$SCRIPT")
export LD_LIBRARY_PATH="$SCRIPTPATH"
export QT_QPA_PLATFORM_PLUGIN_PATH="$SCRIPTPATH/plugins/platforms"
"$SCRIPTPATH/Application" &

[VRHans]

@FireEarl I'm going to bump this to paid support (we have a commercial license) so if they solve this I'll post the result here.

I'm using the gcc 64 libs that Qt themselves built and shipped and still haven't found a way around this (I put it aside for a bit to polish up the Windows/OSX side of things.)

Probably the easiest solution would be for someone to create an example gzip/tar/whatever of the Qt minibrowser sample on Linux that was totally self contained (without static linking of course.)

This would be an relatively simple example of exactly what to do that included a widespread of potential dependencies (QTWebEngineProcess, QML, Xcb platform plugin, et cetera.)

The weird thing is that if I don't hide my Qt directory everything works fine, if I do hide it I get the Xcb error. I'll submit to support and then try running down all the individual dependencies of the Xcb shared object library. I thought I'd done that last time I tried to fix this and saw only references to system library paths, but I'll double check.

[VRHans]

Strangely the problem seems to be related to the Qt/<version#>/gcc_64/plugins/xcbglintegrations directory.

I hide everything from Qt EXCEPT this directory it starts up fine.
If I hide this directory it fails with the error we are both getting.

Here's the weird part - if I rename the SOs in that directory to hide them, they are found anyhow and the app loads just fine.

If I move them into a subdirectory, the app fails to load.

They are NOT listed as dependencies to my application or the platform plugin, suggesting that they are explicitly loaded at runtime via a direct load call and that load call seems to enumerate any SO in that specific directory (since I can rename the files and it still loads.)

If I move either of them to their original directory I can name them anything I want and the app will load and run properly. E.g. I renamed the file to something bizarre:

mv libqxcb-egl-integration.so wtfisgoingon.dll

And the application still loaded and ran fine.

This seems to be a real issue since something is hardcoded to look in that specific directory for any files in it...

[kshegunov]

@VRHans
Hi,
See the last part of the deployment page. Since you're deploying your own set of Qt binaries I think the note about paths is relevant:

The search path for Qt plugins (as well as a few other paths) is hard-coded into the QtCore library. By default, the first plugin search path will be hard-coded as /path/to/Qt/plugins. As mentioned above, using predetermined paths has certain disadvantages, so you need to examine various alternatives to make sure that the Qt plugins are found:

Have you tried providing your own qt.conf that sets the search paths for the plugins?

Kind regards.

[VRHans]

@kshegunov said:

last part

As far as I can tell, this is exactly what the example shell script from the linux deployment page is supposed to handle.

I use the default file layout in my application directory as those found in the qt.conf specification.

I know, for a certainty, that my application can find other Qt plugins properly because when I unhide those two libqxcb- shared libraries, the app runs and loads all the other plugins in my plugins directory (like svg support) just fine (in other words, I hide everything in the Qt folder except those those two SOs.)

It is only those two SOs that seem be to be loaded via dlopen and the runtime (I presume the platform plugin) enumerates ANY file inside of that hardcoded path. Very strange.

Then again, I may be wrong, but I'm trying to be careful about that...

[VRHans]

Just managed to fix this by explicitly overriding the plugins in the shell script like this:

export QT_PLUGIN_PATH=$dirname/plugins

Where $dirname is the directory containing the executable.

Odd that this solves the issue as Qt found all the other necessary plugins without it.

Note that I had to place the two .so files in the directory like this:

/<deployment_dir>/plugins/xcbglintegrations/libqxcb-egl-integration.so
/<deployment_dir>/plugins/xcbglintegrations/libqxcb-glx-integration.so

Must be tied to code that enumerates Xcb integration plugins.

Anyhow, glad to have gotten past this.

@kshegunov I should have thought less and just blindly followed your advice ;) Would have gotten farther faster. Cheers!

[kshegunov]

@VRHans said:

I should have thought less and just blindly followed your advice ;) Would have gotten farther faster.

Perhaps, but thinking less is never good advice. ;)
I'm glad you were able to solve it.

Cheers!

[FireEarl]

Thanks, it also worked in my scenario!
Hope this will be added to the Deployment page of Qt / WebEngine.

[VRHans]

@FireEarl Cool :)

There's probably a reason that it works this way, but if not - these plugins should work the same way the others do.

[kshegunov]

@VRHans said:

There's probably a reason that it works this way, but if not - these plugins should work the same way the others do.

If my initial suspicion, based on your description of renaming libraries and folders, is correct, then you had used the system installed integration plugins instead of the ones you deployed. Thus before overriding the plugin search path the plugins are searched for in the wrong place, at least that's what I suspect.

@FireEarl said:

Hope this will be added to the Deployment page of Qt / WebEngine.

It kind of is, I quoted exactly the deployment page. Perhaps it could be rephrased to be more explicit, but the info is there.

Kind regards.