In some systems the OpenGL library cannot be found if the pkg-config module is called “opengl” (and henceforth values picked from “opengl.pc”) instead of plainly “gl” (with values from “gl.pc”). One such case are systems where libglvnd (https://github.com/NVIDIA/libglvnd) is used as main GL library, letting it dispatch to the most suitable OpenGL implementation at runtime depending on the system state. In this case the main library would be libOpenGL.so.0 instead of libGL.so.1 and/or libGLX.so.0; then libOpenGL.so.0 will handle dispatching lib(EGL|GLX)_<vendor>.so.<N> (for example libEGL_mesa.so.0 for non-X11 operation with free software Mesa drivers, or libGLX_nvidia.so.0 when running under X with the proprietary Nvidia driver). Some notes: - If opengl.pc is found, the library name will be libOpenGL.so.0, and it will *not* contain GLX symbols. In that case we need to search for glx.pc as well, which may include additional flags/libraries that one needs to link in order to get the GLX symbols. - If gl.pc is found, it can either be provided by libglvnd or not; and in both cases linking to the library specified in the pkg-config module *will* result in being able to find the GLX symbols. Therefore: - If opengl.pc is *not* found (no libglvnd), we want to keep our existing logic: try gl.pc first, fall back to checking the “gl” and “GL” library names, and try to figure out whether GLX headers can be found. - If opengl.pc is found (libglvnd present), we should prefer that as the GL library to link against, and we need to check for the existence of glx.pc to determine whether GLX_FOUND should be set. - If opengl.pc is found but glx.pc is *not* found we might want to fallback to the checking for the gl.pc and the GLX headers as stated above. Thanks for Haelwenn “lanodan” Monnier who pointed out on IRC that Gentoo has been carrying a patch to change the checked pkg-config module and library names to use libglvnd, which allows them to successfully build WebKitGTK :]
While at it, maybe it would be a good idea to try and convert the FindOpenGL.cmake file to use imported targets \o/
Created attachment 451902 [details] Patch against WebKitGTK 2.34.3 for X11-less OpenGL Hi, Actually the patch in question isn't pushed anywhere, including Gentoo, specially because it doesn't works as-is when opengl.pc isn't present, it should always be there on Gentoo's side of things but better be safe than sorry. Adding it as attachment, could try to make it correctly fallback to gl.pc, likely with inspirations from CMake's findOpenGL module (which works quite well). It also includes changes for OpenGLShims.h
(In reply to Adrian Perez from comment #0) > One such case are systems where libglvnd (https://github.com/NVIDIA/libglvnd) > is used as main GL library, letting it dispatch to the most suitable OpenGL > implementation at runtime depending on the system state. Not so on Fedora, this is easy to disprove: $ pkg-config --cflags --libs opengl -lOpenGL $ pkg-config --cflags --libs gl -lGL $ rpm -qf /usr/lib64/pkgconfig/gl.pc libglvnd-devel-1.3.4-2.fc35.x86_64 $ rpm -qf /usr/lib64/pkgconfig/opengl.pc libglvnd-devel-1.3.4-2.fc35.x86_6 $ rpm -qf /usr/lib64/libOpenGL.so.0.0.0 libglvnd-opengl-1.3.4-2.fc35.x86_64 $ rpm -qf /usr/lib64/libGL.so.1.7.0 libglvnd-glx-1.3.4-2.fc35.x86_64 All of the above are provided by glvnd.
(In reply to Michael Catanzaro from comment #3) > (In reply to Adrian Perez from comment #0) > > One such case are systems where libglvnd (https://github.com/NVIDIA/libglvnd) > > is used as main GL library, letting it dispatch to the most suitable OpenGL > > implementation at runtime depending on the system state. > > Not so on Fedora, this is easy to disprove: > > $ pkg-config --cflags --libs opengl > -lOpenGL > $ pkg-config --cflags --libs gl > -lGL > > $ rpm -qf /usr/lib64/pkgconfig/gl.pc > libglvnd-devel-1.3.4-2.fc35.x86_64 > $ rpm -qf /usr/lib64/pkgconfig/opengl.pc > libglvnd-devel-1.3.4-2.fc35.x86_6 > > $ rpm -qf /usr/lib64/libOpenGL.so.0.0.0 > libglvnd-opengl-1.3.4-2.fc35.x86_64 > $ rpm -qf /usr/lib64/libGL.so.1.7.0 > libglvnd-glx-1.3.4-2.fc35.x86_64 > > All of the above are provided by glvnd. On Arch Linux we have the same as for Fedora, but that's not the case in every system where libglvnd is used. At any rate, even if libglvnd *usually* provides libGL.so.1 for backwards-compat, linking against it is considered a legacy practice because programs that use EGL will end up linked against X11 libraries unneedlessly, which is the reason for preferring using -lOpenGL/opengl.pc and then iff a program purposedfully uses GLX, adding -lGLX/glx.pc.
While at it, I am revamping our FindOpenGL.cmake module to define imported targets so it will define OpenGL::OpenGL and OpenGL::GLX, which is more robust and will allow simplifying other places of the build system that make use of variables defined by the module.
Created attachment 452176 [details] Patch
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE
Created attachment 452185 [details] Patch v2 This should make the WPE build green.
Dude... would you even still need this FindOpenGL.cmake if you switched to epoxy? It looks like you're going far out of your way to avoid a big simplification of the code. Still good to land, though, since it fixes a build failure and is better than we have now. I was going to give r=me, but Don beat me to it.
(In reply to Michael Catanzaro from comment #9) > Dude... would you even still need this FindOpenGL.cmake if you switched to > epoxy? It looks like you're going far out of your way to avoid a big > simplification of the code. > > Still good to land, though, since it fixes a build failure and is better > than we have now. I was going to give r=me, but Don beat me to it. I would like to see the libepoxy requirement go away and its either you do a system OpenGL ES 2/3 or ANGLE.
(In reply to Don Olmstead from comment #10) > I would like to see the libepoxy requirement go away and its either you do a > system OpenGL ES 2/3 or ANGLE. We don't currently require libepoxy, but are planning to. I don't know why you'd like to see it go, because it would eliminate all of this complexity (e.g. OpenGLShims.h, etc.)
(In reply to Michael Catanzaro from comment #11) > We don't currently require libepoxy, but are planning to. I suppose we could limit this to WPE/GTK only.
(In reply to Michael Catanzaro from comment #12) > (In reply to Michael Catanzaro from comment #11) > > We don't currently require libepoxy, but are planning to. > > I suppose we could limit this to WPE/GTK only. My understanding is you all want to enable WebGL 2 and that requires ANGLE and ANGLE would thus handle all of the things libepoxy is handling for you. That's why I would assume you all would get rid of it in the future.
Hm, I dunno. We have bug #235626 for that.
Committed r289949 (247351@main): <https://commits.webkit.org/247351@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 452185 [details].
<rdar://problem/89045498>
Breaks WPE builds with -DUSE_ANGLE_WEBGL=ON: > CMake Error at Source/ThirdParty/ANGLE/CMakeLists.txt:150 (add_library): > Target "GLESv2" links to target "OpenGL::GLES" but the target was not > found. Perhaps a find_package() call is missing for an IMPORTED target, or > an ALIAS target is missing? > > > CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library): > Target "WebCore" links to target "OpenGL::GLES" but the target was not > found. Perhaps a find_package() call is missing for an IMPORTED target, or > an ALIAS target is missing? > Call Stack (most recent call first): > Source/WebCore/CMakeLists.txt:2106 (WEBKIT_FRAMEWORK_DECLARE) > > > CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library): > Target "WebCoreTestSupport" links to target "OpenGL::GLES" but the target > was not found. Perhaps a find_package() call is missing for an IMPORTED > target, or an ALIAS target is missing? > Call Stack (most recent call first): > Source/WebCore/CMakeLists.txt:2107 (WEBKIT_FRAMEWORK_DECLARE) > > > CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library): > Target "WebKit" links to target "OpenGL::GLES" but the target was not > found. Perhaps a find_package() call is missing for an IMPORTED target, or > an ALIAS target is missing? > Call Stack (most recent call first): > Source/WebKit/CMakeLists.txt:450 (WEBKIT_FRAMEWORK_DECLARE) > > > CMake Error at Source/cmake/WebKitMacros.cmake:125 (add_library): > Target "TestRunnerShared" links to target "OpenGL::GLES" but the target was > not found. Perhaps a find_package() call is missing for an IMPORTED > target, or an ALIAS target is missing? > Call Stack (most recent call first): > Tools/TestRunnerShared/CMakeLists.txt:1 (WEBKIT_FRAMEWORK_DECLARE) > > > CMake Error at Source/cmake/WebKitMacros.cmake:129 (add_executable): > Target "WebKitTestRunner" links to target "OpenGL::GLES" but the target was > not found. Perhaps a find_package() call is missing for an IMPORTED > target, or an ALIAS target is missing? > Call Stack (most recent call first): > Tools/WebKitTestRunner/CMakeLists.txt:136 (WEBKIT_EXECUTABLE_DECLARE) > > (repeated for I guess every other target)
Re-opened since this is blocked by bug 236757
(In reply to WebKit Commit Bot from comment #18) > Re-opened since this is blocked by bug 236757 Gah, I did try a GTK build with -DUSE_ANGLE_WEBGL=ON and -DENABLE_WEBGL2=ON, which succeeded, but not a WPE build. I'll give it try and make sure WPE also builds fine before updating the patch again.
Created attachment 452507 [details] Patch v3 This fixes the build issues when using USE_ANGLE_WEBGL=ON for the WPE port, which caused the revert of the previous version of the patch. I have tested that both the GTK and WPE ports can be built successfully with the options USE_ANGLE_WEBGL and ENABLE_WEBGL2 enabled.
Committed r290138 (247479@main): <https://commits.webkit.org/247479@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 452507 [details].