Bug 105328

Summary: Can't include gl and gles headers simultaneously on non-64 bit architectures
Product: Mesa Reporter: Iain Lane <iain>
Component: OtherAssignee: Emil Velikov <emil.l.velikov>
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: agomez, mattst88, siglesias, slomo, tim
Version: git   
Hardware: Other   
OS: All   
URL: https://github.com/KhronosGroup/OpenGL-Registry/issues/162
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 108530    
Attachments: can you include GLES2/gl2.h and GL/gl.h at the same time?

Description Iain Lane 2018-03-02 16:12:21 UTC
Created attachment 137755 [details]
can you include GLES2/gl2.h and GL/gl.h at the same time?

mesa 1.8 rc4 on Ubuntu Bionic

I was just chatting with gstreamer upstream about a build failure we/they are seeing, where we can't build gst-plugins-good on arm. Excerpt from https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0&arch=armhf&ver=1.13.1-1&stamp=1519744588&raw=0:

In file included from /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopengl.h:105:0,
                 from /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglfunctions.h:54,
                 from /usr/include/arm-linux-gnueabihf/qt5/QtGui/QOpenGLFunctions:1,
                 from gstqsgtexture.h:30,
                 from gstqsgtexture.cc:31:
/usr/include/GLES3/gl31.h:77:25: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;
                         ^~~~~~~~~~
In file included from /usr/include/GL/gl.h:2055:0,
                 from /usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:68,
                 from gstqsgtexture.cc:30:
/usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;
                   ^~~~~~~~~~

The problem is that Qt is built with GLES on arm - it ends up including gl31.h which can't be included together with glext.h that gstreamer brings in.

However, this *does* work on amd64. I'm attaching a .c file extracted from gstreamer's build system that tests if you can include <GLES2/gl2.h> and <GL/gl.h> at the same time. This compiles fine on amd64/arm64/ppc64el for me, but not i386/armhf.

Is this supposed to work or is it an accident that you can do it on 64 bit?
Comment 1 Ilia Mirkin 2018-03-02 16:19:37 UTC
GL headers come from Khronos and are (should be) standard across all GL implementations.
Comment 2 Brian Paul 2018-03-02 17:06:41 UTC
Evidently, the problem with the 32-bit build is that ptrdiff_t is not equivalent to signed long int.

This hack works for me:

#include <stddef.h>
#include <GLES2/gl2.h>
#define GL_VERSION_1_5
#include <GL/gl.h>
int main (int argc, char **argv) { return 0; }

This basically causes the GL_VERSION_1_5 section in glext.h to be skipped.  If you need definitions from that section, you'd probably have to copy&paste them.

I proper fix would probably involve adding #ifndef GLSIZEIPTR / #endif guards around the typedefs.  That would have to be done upstream in the Khronos headers.
Comment 3 Eric Engestrom 2018-03-02 17:09:26 UTC
As Ilia mentioned, these headers come directly from Khronos; I've just raised a ticket with your issue there (https://github.com/KhronosGroup/OpenGL-Registry/issues/162), but to answer your question: yes, supporting GL & GLES3 at the same time is meant to be possible, and it's a bug that it doesn't work.
Comment 4 Brian Paul 2018-03-02 17:22:40 UTC
(In reply to Brian Paul from comment #2)
> Evidently, the problem with the 32-bit build is that ptrdiff_t is not
> equivalent to signed long int.
> 
> This hack works for me:
> 
> #include <stddef.h>
> #include <GLES2/gl2.h>
> #define GL_VERSION_1_5
> #include <GL/gl.h>
> int main (int argc, char **argv) { return 0; }
> 
> This basically causes the GL_VERSION_1_5 section in glext.h to be skipped. 
> If you need definitions from that section, you'd probably have to copy&paste
> them.
> 
> I proper fix would probably involve adding #ifndef GLSIZEIPTR / #endif
> guards around the typedefs.  That would have to be done upstream in the
> Khronos headers.

On second thought, including khrplatform.h in glext.h and changing the typedefs to read
typedef khronos_ssize_t GLsizeiptr;
typedef khronos_intptr_t GLintptr;

would be pretty simple.  I added this to Eric's Khronos bug report.
Comment 5 Sebastian Dröge (slomo) 2018-03-05 07:54:57 UTC
Is there any chance of getting this fixed before Khronos releases a new version of the headers? I assume that usually takes quite a while, if they agree to include this change at all?
Comment 6 Adrian Perez de Castro 2018-07-22 11:11:14 UTC
I just saw this bug being mentioned in #webkitgtk+, so I have CC'd
a coupld of igalians who are working actively on Mesa.
Comment 7 Matt Turner 2018-11-02 21:33:17 UTC
Eric reported this upstream and it's now marked as fixed. Perhaps he can do whatever is needed to propagate this into Mesa (probably just importing the headers and confirming you can include both?)
Comment 8 Emil Velikov 2018-11-12 18:08:10 UTC
Matt has noticed that this is causing problems on Gentoo https://bugs.gentoo.org/660594

Although it's related to building gst the problem is the same. The gst check was introduced in 2017 with
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?h=8227135f3b

While Mesa had "typedef khronos_ssize_t GLsizeiptr;" and "typedef ptrdiff_t GLsizeiptr;" for GLES* and GL respectively since the headers were introduced.

Issue is addressed since commit f7d42ee7d319256608ad60778f6787c140badada
although that involves shipping KHR/khrplatform.h which wasn't before.

For the latter we'll need the following commits:
87c156183cd668f1341326cc7c88ab6686f27d8f
e02f061b690def50060bcca76706e6407b83260f

I'll forward them for the 18.2 series. The 18.3 branch has all the commits.
Comment 9 Eric Engestrom 2018-11-14 10:47:37 UTC
Marking as FIXED as it should be fixed in mesa master and 18.3.*, and the upcoming 18.2.5 (as of 82faa8067a8872c877eb21122130cf5bdc86657e)

Ian, Sebastian & Adrian, please test with your respective builds that you are not seeing any issues related to this anymore, and feel free to re-open this issue if you do :)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.