1

Qt 6 has removed the support for ANGLE for their OpenGL backend. Now I would still like to use ANGLE with Qt because I would like to run custom OpenGL code that is translated by ANGLE to Vulkan Linux and Direct3D on Windows. I've tried to use ANGLE in my Qt 6 application, but without success. What I have tried is:

Build ANGLE from source files (on Linux) as per instructions (ANGLE build instructions).

Copied the generated libGLESv2.so and libEGL.so files into application directory. Then in my CMakeFiles.txt I have added:

find_library(libGLESv2 GLESv2)
find_library(libEGL EGL)
target_link_libraries(MyApp PRIVATE ${libGLESv2} ${libEGL})

Then in my main file I have added

QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);
QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL);

My project links and builds fine, but the ANGLE backend seems to have no effect. It appears that Qt is still using the standard OpenGL implementation rather than the one provided by ANGLE (running QOpenGLContext::currentContext()->hasExtension("EGL_ANGLE_platform_angle") returns false when I set up my context).

Using QT_LOGGING_RULES=qt.qpa.gl=true,the logs show:

qt.qpa.gl: Choosing xcb gl-integration based on following priority ("xcb_glx", "xcb_egl") qt.qpa.gl: Xcb GLX gl-integration created qt.qpa.gl: Xcb GLX gl-integration successfully initialized qt.qpa.gl: Requested format before FBConfig/Visual selection: QSurfaceFormat(version 3.0, options QFlagsQSurfaceFormat::FormatOption(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile)

How can I correctly setup Qt to rely on ANGLE?

reckless
  • 741
  • 12
  • 53
  • Please post a link to a buildable project that shows this issue under Linux, preferably Ubuntu 20.04 or Debian 11. It's got nothing to do with Qt 6, but you might want to take a look at WaylandGUI CMakeLists.txt. https://github.com/RolandHughes/waylandgui I had a similar issue when trying to force linkage of GLES. Too many things that started X11 look for the oldest X11 support they can find. Also check this: https://doc.qt.io/qt-6/embedded-linux.html – user3450148 Jan 24 '22 at 18:23
  • @user3450148 the behaviour can be reproduced with any opengl app in Qt (you can try this example https://pastebin.pl/view/94d5fee4 after linking the angle libraries as I suggested in my question using CMake). – reckless Jan 26 '22 at 18:24

1 Answers1

-2

Okay,

When I asked for a buildable project that reproduces the problem I didn't mean a snippet of source without the CMakeLists.txt that is causing the problem. I spent a good 4 hours trying to duplicate your environment blind. Nobody uses Qt 6 because it is horrible.

The first problem is you can't "just copy" libs. GLES libs GLES before copy

EGL libs GLS libs before copy

After copy

enter image description here

the build and runtime system wants its series of links. When you copy you loose that because you get multiple copies of the same file rather than one copy with a bunch of links. If you are going to use these libraries you need to use them from an installed location or the original build location.

I wanted to prove this solution to you rather than just tell you, but I ran into the same problem 98.5% of all developers run into when anything Android is installed near Qt.

I wanted you to look at the CMakeLists.txt file for WaylandGUI not because it is some shining example of wonderful, rather so you see how to use message() to dump your cmake variables. This is the "default debugger" when troubleshooting cmake issues.

You aren't properly using find_library()

https://cmake.org/cmake/help/latest/command/find_library.html

Had you installed the ANGLE library you built there is a 50/50 chance find_library would have found it. One would need to dump the cmake variables to see where it looked and what it found and to do that you need message().

In particular read up on CMAKE_PREFIX_PATH and the PATHS option for find_library(). If the documentation seems clear as mud you can view this SO discussion on CMAKE_PREFIX_PATH.

cmake - find_library - custom library location

The other command you need to know is ldd. It's really shocking how many people developing on Linux that don't know this command.

ldd of an example program

What ldd does, from a high conceptual level, is tell you every library the loader is going to use when running your executable, at least from an initial load standpoint. The executable itself may be able to force load other libraries at run time. When an executable dies before it starts you can use ldd to track down what library (or library used by a library) cannot be found.

In your particular case, ldd will tell you what GLES and EGL libraries were used during link. By default find_library() looks in "the usual places" first which isn't your local build directory. The problem you are running into is you are trying to replace an existing system library in your link. Here's a very detailed write-up on how to use HINTS and such with find_library().

Without being able to replicate your build environment and without a complete buildable example replicating the problem I cannot be of further help.

user3450148
  • 851
  • 5
  • 13
  • 1
    Aside from Qt 6 not being horrible, ldd does not "show you what libraries were used during link". What ldd does is show you what the dynamic executable loader and runtime linker finds when you actually execute your application. Apart from things like LD_LIBRARY_PATH and just, well, moving libraries around in your filesystem, ldd output will definitely vary depending on your actions independent of what was done "during link". – rubenvb Feb 09 '23 at 22:39
  • Aside from the fact Qt 6 is looking up at horrible hoping to one day be that good, the answer clearly states: What ldd does, from a high conceptual level, is tell you every library the loader is going to use when running your executable, – user3450148 Feb 11 '23 at 00:21