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

• Component: WebKitGTK
• Status: RESOLVED DUPLICATE

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

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'

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

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]

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]

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]

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]

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

[Michael Catanzaro]

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]

(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]

(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]

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]

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]

(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]

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]

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]

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