RESOLVED FIXED248032
[WPE][GTK] TextureMapperPlatformLayerDmabuf.cpp:107:5: error: 'glEGLImageTargetTexture2DOES' was not declared in this scope
https://bugs.webkit.org/show_bug.cgi?id=248032
Summary [WPE][GTK] TextureMapperPlatformLayerDmabuf.cpp:107:5: error: 'glEGLImageTarg...
Michael Catanzaro
Reported 2022-11-17 05:28:28 PST
WebKitGTK 2.39.1 does not build in Fedora rawhide or in GNOME master: /builddir/build/BUILD/webkitgtk-2.39.1/Source/WebCore/platform/graphics/texmap/TextureMapperPlatformLayerDmabuf.cpp: In member function 'void WebCore::TextureMapperPlatformLayerDmabuf::validateTexture()': /builddir/build/BUILD/webkitgtk-2.39.1/Source/WebCore/platform/graphics/texmap/TextureMapperPlatformLayerDmabuf.cpp:107:5: error: 'glEGLImageTargetTexture2DOES' was not declared in this scope 107 | glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /builddir/build/BUILD/webkitgtk-2.39.1/Source/WebCore/platform/graphics/texmap/TextureMapperPlatformLayerProxyDMABuf.cpp: In static member function 'static std::unique_ptr<WebCore::TextureMapperPlatformLayerProxyDMABuf::DMABufLayer::EGLImageData> WebCore::TextureMapperPlatformLayerProxyDMABuf::DMABufLayer::createEGLImageData(WebCore::DMABufObject&)': /builddir/build/BUILD/webkitgtk-2.39.1/Source/WebCore/platform/graphics/texmap/TextureMapperPlatformLayerProxyDMABuf.cpp:323:9: error: 'glEGLImageTargetTexture2DOES' was not declared in this scope 323 | glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, data.image[i]); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ (There might be more such failures.) My local builds work perfectly fine, though. Looking in GL/gl.h, I see this: #ifndef GL_OES_EGL_image #define GL_OES_EGL_image 1 #ifdef GL_GLEXT_PROTOTYPES GLAPI void APIENTRY glEGLImageTargetTexture2DOES (GLenum target, GLeglImageOES image); GLAPI void APIENTRY glEGLImageTargetRenderbufferStorageOES (GLenum target, GLeglImageOES image); #endif typedef void (APIENTRYP PFNGLEGLIMAGETARGETTEXTURE2DOESPROC) (GLenum target, GLeglImageOES image); typedef void (APIENTRYP PFNGLEGLIMAGETARGETRENDERBUFFERSTORAGEOESPROC) (GLenum target, GLeglImageOES image); #endif This suggests that WebKit needs to define GL_GLEXT_PROTOTYPES before including the header if it wants to get this declaration, but we don't do that anywhere. I am testing a build with -DGL_GLEXT_PROTOTYPES=1 now to see if it works. As to where we should define this value... I suppose it would need to be at the very top of OpenGLShims.h. I'm not sure why WebKit builds properly for me locally. Guess #1: different unified source bundles? WebKit does define GL_GLEXT_PROTOTYPES to 0 in ANGLEHeaders.h. That's surely intended to turn it off, but actually turns it on because gl.h only checks whether it is defined, not what its value is. That ANGLEHeaders.h contains a warning: // Note: this file can't be compiled in the same unified source file // as others which include the system's OpenGL headers. If we were to fail to respect that rule, then it could accidentally make the declaration of glEGLImageTargetTexture2DOES available. Guess #2: when WebKit builds successfully, it's not actually including the system GL/gl.h (which seems to be desired), but is instead including ANGLE's from Source/ThirdParty (by accident?).
Attachments
Michael Catanzaro
Comment 1 2022-11-17 07:07:09 PST
(In reply to Michael Catanzaro from comment #0) > As to where we should define this value... I suppose it would > need to be at the very top of OpenGLShims.h. This actually fixes the build, so I'll submit a merge request, though I don't know if it is the correct solution.
Michael Catanzaro
Comment 2 2022-11-17 07:13:26 PST
Michael Catanzaro
Comment 3 2022-11-17 08:13:12 PST
(In reply to Michael Catanzaro from comment #1) > This actually fixes the build, Uh-oh, looks like this doesn't actually work. I tested this in a GNOME master build on x86_64, but had not confirmed that the build failure actually happens on x86_64. Hmm....
Michael Catanzaro
Comment 4 2022-11-18 07:40:24 PST
*** Bug 248081 has been marked as a duplicate of this bug. ***
Michael Catanzaro
Comment 5 2022-11-18 08:38:45 PST
Presumably bug #248074 is intended to fix this. I am testing it now.
Michael Catanzaro
Comment 6 2022-11-18 11:08:43 PST
Pawel Lampe
Comment 7 2025-10-16 00:53:54 PDT
The above PR landed already, can we close this issue?
Adrian Perez
Comment 8 2025-10-16 01:23:19 PDT
(In reply to Pawel Lampe from comment #7) > The above PR landed already, can we close this issue? Yup, let's close it.
Note You need to log in before you can comment on or make changes to this bug.