WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
248032
[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
Add attachment
proposed patch, testcase, etc.
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
Pull request:
https://github.com/WebKit/WebKit/pull/6589
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
This is indeed fixed by
https://github.com/WebKit/WebKit/pull/6623
.
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.
Top of Page
Format For Printing
XML
Clone This Bug