Bug 208907

Summary:

[GTK] graphics/GLContext.cpp fails compiling with error: ‘initializeOpenGLShims’ was not declared in this scope; did you mean ‘initializeOpenGLShimsIfNeeded’?

Product:

WebKit

Reporter:

Дилян Палаузов <dpa-webkit>

Component:

WebKitGTK

Assignee:

Adrian Perez <aperez>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

aperez, berto, bugs-noreply, cgarcia, ews-watchlist, gustavo, leio, mcatanzaro

Priority:

Version:

WebKit Local Build

Hardware:

Unspecified

OS:

Unspecified

See Also:

https://bugs.webkit.org/show_bug.cgi?id=236593

Attachments:

Description	Flags
Patch to make non-X EGL full OpenGL builds succeed	none

Дилян Палаузов

Reported 2020-03-11 01:06:47 PDT

Compiling WebKitGkt 2.28.0 fails with: make[2]: Entering directory '/src/gnome/webkitgtk-2.28.0/build' [ 72%] Building CXX object Source/WebCore/CMakeFiles/WebCore.dir/platform/graphics/GLContext.cpp.o /src/gnome/webkitgtk-2.28.0/Source/WebCore/platform/graphics/GLContext.cpp: In function ‘bool WebCore::initializeOpenGLShimsIfNeeded()’: /src/gnome/webkitgtk-2.28.0/Source/WebCore/platform/graphics/GLContext.cpp:66:19: error: ‘initializeOpenGLShims’ was not declared in this scope; did you mean ‘initializeOpenGLShimsIfNeeded’? 66 | success = initializeOpenGLShims(); | ^~~~~~~~~~~~~~~~~~~~~ | initializeOpenGLShimsIfNeeded /src/gnome/webkitgtk-2.28.0/Source/WebCore/platform/graphics/GLContext.cpp: In member function ‘unsigned int WebCore::GLContext::version()’: /src/gnome/webkitgtk-2.28.0/Source/WebCore/platform/graphics/GLContext.cpp:171:71: error: ‘::glGetString’ has not been declared; did you mean ‘res_getString’? 171 | String versionString = String(reinterpret_cast<const char*>(::glGetString(GL_VERSION))); | ^~~~~~~~~~~ | res_getString /src/gnome/webkitgtk-2.28.0/Source/WebCore/platform/graphics/GLContext.cpp:171:83: error: ‘GL_VERSION’ was not declared in this scope; did you mean ‘GCC_VERSION’? 171 | String versionString = String(reinterpret_cast<const char*>(::glGetString(GL_VERSION))); | ^~~~~~~~~~ | GCC_VERSION make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/build.make:7769: Source/WebCore/CMakeFiles/WebCore.dir/platform/graphics/GLContext.cpp.o] Error 1 make[2]: Leaving directory '/src/gnome/webkitgtk-2.28.0/build'

Attachments
Patch to make non-X EGL full OpenGL builds succeed (1.62 KB, patch) 2020-05-09 13:46 PDT, Mart Raudsepp	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Дилян Палаузов

Comment 1 2020-03-11 01:47:14 PDT

GlContext.cpp contains: #if USE(GLX) #include "GLContextGLX.h" #include "OpenGLShims.h" #endif static bool initializeOpenGLShimsIfNeeded() { #if USE(OPENGL_ES) || USE(LIBEPOXY) return true; #else static bool initialized = false; static bool success = true; if (!initialized) { success = initializeOpenGLShims(); initialized = true; } return success; #endif } So when GLX, OPENGL_ES and LIBEPOXY are not defined, which somehow happens to be the case on my system, compilation fails. My system does have libepoxy 1.5.3.

Mart Raudsepp

Comment 2 2020-05-09 12:43:05 PDT

Source/WebCore/platform/graphics/GLContext.cpp is including OpenGLShims.h only if GLX is enabled, but then using the initializeOpenGLShims function in other cases as well. I think the preprocessor conditionals should match better. As-is, it seems to guarantee a fail for a -DENABLE_X11_TARGET=OFF -DENABLE_OPENGL=ON build that picks OpenGL. Basically initializeOpenGLShimsIfNeeded seems to think that a EGL+full OpenGL (instead of GLX) doesn't exist or happen, but libepoxy isn't used at all for a webkitgtk build (I guess it might be used in webkit-wpe or something)

Mart Raudsepp

Comment 3 2020-05-09 12:45:02 PDT

while there, I also notice that initializeOpenGLShimsIfNeeded tracks initialized and success states, to not call it multiple times - but initializeOpenGLShims already (or by now) does exactly that as well, so that feels superfluous there in initializeOpenGLShimsIfNeeded

Mart Raudsepp

Comment 4 2020-05-09 13:46:52 PDT

Created attachment 398939 [details] Patch to make non-X EGL full OpenGL builds succeed I'm not happy about this patch, as it doesn't adjust things to be similar in all the places, but enough to get the build issue I was having fixed. Looking into this, I found that various OpenGLShims.h usages are quite different from each other in their conditionals. So some places assume it's only needed for GLX, while others don't know anything about ANGLE being a thing yet, etc. I don't know the context and maze of compile conditionals enough to really know how to do this properly, so meanwhile I'm going to try using this attached patch in Gentoo. Note that this patch contains changes to another file issue as well, not just GLContext.cpp, as after fixing GLContext, the build reaches the next issue there. I'm going to also have it build various different build configurations in the background on a big aarch64 box; if I don't report back here, all of those succeed with this patch included. Otherwise I'll have to update the patch to make all the build combinations we try to support work, and will post it here as well for consideration or ideas.

Michael Catanzaro

Comment 5 2020-05-13 06:51:28 PDT

Please be careful when selecting Bugzilla components... if you don't select WebKitGTK, the bug is likely to be ignored.

Michael Catanzaro

Comment 6 2020-05-13 07:12:55 PDT

Trying to find when this broke... I'm not sure. That header was *added* to the file in r249909. Prior to that commit, it must have been included from some other header. The guards are clearly incorrect since the shims are initialized outside the USE(GLX) codepath, so your patch is an improvement at least. (In reply to Mart Raudsepp from comment #4) > Looking into this, I found that various OpenGLShims.h usages are quite > different from each other in their conditionals. So some places assume it's > only needed for GLX, while others don't know anything about ANGLE being a > thing yet, etc. Yeah I agree this seems to be pretty messed up. Needs to be investigated by graphics developers.

Adrian Perez

Comment 7 2020-06-30 04:26:52 PDT

(In reply to Mart Raudsepp from comment #2) > Source/WebCore/platform/graphics/GLContext.cpp is including OpenGLShims.h > only if GLX is enabled, but then using the initializeOpenGLShims function in > other cases as well. I think the preprocessor conditionals should match > better. > As-is, it seems to guarantee a fail for a -DENABLE_X11_TARGET=OFF > -DENABLE_OPENGL=ON build that picks OpenGL. The ENABLE_OPENGL option does not exist, I suppose the idea is to end up with USE_OPENGL=ON, which means setting ENABLE_GRAPHICS_CONTEXT_GL=ON. So yes, I can reproduce the issue by configuring a build with: % cmake -DPORT=GTK -DENABLE_X11_TARGET=OFF -DENABLE_GRAPHICS_CONTEXT_GL=ON > Basically initializeOpenGLShimsIfNeeded seems to think that a EGL+full > OpenGL (instead of GLX) doesn't exist or happen, but libepoxy isn't used at > all for a webkitgtk build (I guess it might be used in webkit-wpe or > something) The WPE port uses libepoxy, but the GTK port does not.

Michael Catanzaro

Comment 8 2020-06-30 09:15:01 PDT

(In reply to Adrian Perez from comment #7) > The WPE port uses libepoxy, but the GTK port does not. It's 2020, probably time to depend on libepoxy?

EWS Watchlist

Comment 9 2021-03-14 09:34:38 PDT

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

Michael Catanzaro

Comment 10 2021-07-24 08:41:32 PDT

Hey Adrian, I think we need someone more familiar with OpenGL to unbreak the -DENABLE_X11_TARGET=OFF builds. Any chance you could help? (In reply to Michael Catanzaro from comment #8) > It's 2020, probably time to depend on libepoxy? libepoxy has been around for long enough that I think it's entirely reasonable to make it a hard dep. I assume that would make things a lot simpler.

Adrian Perez

Comment 11 2021-11-08 01:05:18 PST

(In reply to Michael Catanzaro from comment #10) > Hey Adrian, I think we need someone more familiar with OpenGL to unbreak the > -DENABLE_X11_TARGET=OFF builds. Any chance you could help? > > (In reply to Michael Catanzaro from comment #8) > > It's 2020, probably time to depend on libepoxy? > > libepoxy has been around for long enough that I think it's entirely > reasonable to make it a hard dep. I assume that would make things a lot > simpler. I hadn't stepped in before because I didn't manage to reproduce the build issue, but recently this build issue came up with 2.32.x in one of the Buildroot autobuilders: http://autobuild.buildroot.net/results/2fbbf65a3dd8b6916fadb459af1b308f88b58554/ This means there we have now a build config file that can be used to trigger this build failure deterministically. I will give it a go and see if this is still a problem in 2.34.x and in trunk :)

Mart Raudsepp

Comment 12 2021-11-08 02:39:41 PST

In 2.34.x there's various issues with different build configurations. I'm applying https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/webkit-gtk/files/2.34.1-opengl-without-X-fixes.patch but that's not enough for all combinations. Need to start with making sure non-unity builds work and then I think there's issues with non-X and/or non-GL builds in 2.34.x.

Mart Raudsepp

Comment 13 2021-11-08 02:56:35 PST

There are my downstream build issues of different failures from different build configurations, many can be tracked down from compilation failure, but I can help figuring out which build option triggers it too: https://bugs.gentoo.org/819384 https://bugs.gentoo.org/820437 https://bugs.gentoo.org/820440 https://bugs.gentoo.org/820443 Some are probably OpenGL related and on-topic here, others are other issues. I'm "leio" on Libera and GNOME IRC if that's better medium to work together on any of these.

Adrian Perez

Comment 14 2022-02-15 00:40:13 PST

I believe the patch in bug #236593 should fix all the issues related to the OpenGLShims.h header. If you still find some remaining issue after it gets merged, please do reopen bug #236593 and let me know :) *** This bug has been marked as a duplicate of bug 236593 ***

Note You need to log in before you can comment on or make changes to this bug.