Bug 248032 - [WPE][GTK] TextureMapperPlatformLayerDmabuf.cpp:107:5: error: 'glEGLImageTargetTexture2DOES' was not declared in this scope
Summary: [WPE][GTK] TextureMapperPlatformLayerDmabuf.cpp:107:5: error: 'glEGLImageTarg...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Michael Catanzaro
URL:
Keywords:
: 248081 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-11-17 05:28 PST by Michael Catanzaro
Modified: 2022-11-18 11:08 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 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?).
Comment 1 Michael Catanzaro 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.
Comment 2 Michael Catanzaro 2022-11-17 07:13:26 PST
Pull request: https://github.com/WebKit/WebKit/pull/6589
Comment 3 Michael Catanzaro 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....
Comment 4 Michael Catanzaro 2022-11-18 07:40:24 PST
*** Bug 248081 has been marked as a duplicate of this bug. ***
Comment 5 Michael Catanzaro 2022-11-18 08:38:45 PST
Presumably bug #248074 is intended to fix this. I am testing it now.
Comment 6 Michael Catanzaro 2022-11-18 11:08:43 PST
This is indeed fixed by https://github.com/WebKit/WebKit/pull/6623.