Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Linux deployment: "QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled"
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Solved General and Desktop
15 Posts 4 Posters 11.7k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    VRHans
    wrote on last edited by
    #3

    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.

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #4

      Do you mean you copied system libraries ?

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • V Offline
        V Offline
        VRHans
        wrote on last edited by
        #5

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

        1 Reply Last reply
        0
        • FireEarlF Offline
          FireEarlF Offline
          FireEarl
          wrote on last edited by
          #6

          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" &

          1 Reply Last reply
          0
          • V Offline
            V Offline
            VRHans
            wrote on last edited by
            #7

            @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.

            1 Reply Last reply
            0
            • V Offline
              V Offline
              VRHans
              wrote on last edited by
              #8

              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...

              kshegunovK 1 Reply Last reply
              1
              • V 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...

                kshegunovK Offline
                kshegunovK Offline
                kshegunov
                Moderators
                wrote on last edited by
                #9

                @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.

                Read and abide by the Qt Code of Conduct

                1 Reply Last reply
                0
                • V Offline
                  V Offline
                  VRHans
                  wrote on last edited by
                  #10

                  @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...

                  1 Reply Last reply
                  0
                  • V Offline
                    V Offline
                    VRHans
                    wrote on last edited by VRHans
                    #11

                    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!

                    kshegunovK 1 Reply Last reply
                    0
                    • V 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!

                      kshegunovK Offline
                      kshegunovK Offline
                      kshegunov
                      Moderators
                      wrote on last edited by
                      #12

                      @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!

                      Read and abide by the Qt Code of Conduct

                      1 Reply Last reply
                      0
                      • FireEarlF Offline
                        FireEarlF Offline
                        FireEarl
                        wrote on last edited by
                        #13

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

                        V 1 Reply Last reply
                        0
                        • FireEarlF FireEarl

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

                          V Offline
                          V Offline
                          VRHans
                          wrote on last edited by
                          #14

                          @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.

                          kshegunovK 1 Reply Last reply
                          0
                          • V 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.

                            kshegunovK Offline
                            kshegunovK Offline
                            kshegunov
                            Moderators
                            wrote on last edited by kshegunov
                            #15

                            @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.

                            Read and abide by the Qt Code of Conduct

                            1 Reply Last reply
                            0
                            • JonBJ JonB referenced this topic on

                            • Login

                            • Login or register to search.
                            • First post
                              Last post
                            0
                            • Categories
                            • Recent
                            • Tags
                            • Popular
                            • Users
                            • Groups
                            • Search
                            • Get Qt Extensions
                            • Unsolved