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"

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.5k Views
  • 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.
  • F Offline
    F Offline
    FireEarl
    wrote on 29 Jul 2016, 08:54 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 29 Jul 2016, 09:51 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 29 Jul 2016, 13:33 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...

        K 1 Reply Last reply 29 Jul 2016, 14:12
        1
        • V VRHans
          29 Jul 2016, 13:33

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

          K Offline
          K Offline
          kshegunov
          Moderators
          wrote on 29 Jul 2016, 14:12 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 29 Jul 2016, 15:07 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 29 Jul 2016, 18:55 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!

              K 1 Reply Last reply 29 Jul 2016, 21:46
              0
              • V VRHans
                29 Jul 2016, 18:55

                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!

                K Offline
                K Offline
                kshegunov
                Moderators
                wrote on 29 Jul 2016, 21:46 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
                • F Offline
                  F Offline
                  FireEarl
                  wrote on 5 Aug 2016, 08:13 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 5 Aug 2016, 14:02
                  0
                  • F FireEarl
                    5 Aug 2016, 08:13

                    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 5 Aug 2016, 14:02 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.

                    K 1 Reply Last reply 6 Aug 2016, 11:07
                    0
                    • V VRHans
                      5 Aug 2016, 14:02

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

                      K Offline
                      K Offline
                      kshegunov
                      Moderators
                      wrote on 6 Aug 2016, 11:07 last edited by kshegunov 8 Jun 2016, 11:09
                      #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
                      • J JonB referenced this topic on 20 Mar 2024, 15:45

                      15/15

                      6 Aug 2016, 11:07

                      • Login

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