Summary: | Can't include gl and gles headers simultaneously on non-64 bit architectures | ||
---|---|---|---|
Product: | Mesa | Reporter: | Iain Lane <iain> |
Component: | Other | Assignee: | 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
GL headers come from Khronos and are (should be) standard across all GL implementations. 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. 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. (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. 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? I just saw this bug being mentioned in #webkitgtk+, so I have CC'd a coupld of igalians who are working actively on Mesa. 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?) 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. 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.