| Summary: | KHR/khrplatform.h not always installed when needed | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Brad King <brad.king> |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
| Severity: | blocker | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Fixed in: commit 87c156183cd668f1341326cc7c88ab6686f27d8f Author: Eric Engestrom <eric.engestrom@intel.com> Date: Tue Aug 7 12:56:25 2018 +0100 configure: install KHR/khrplatform.h when needed Hi all, I see that certain GL headers like "glcorearb.h" needs "KHRplatform.h" header files. This works seamlessly when the GL and EGL providers are MESA. In scenarios where the GL provider is MESA and EGL provider is some GPU vendor say ARM, in that scenario, the khrplatform header comes from two different providers and that results in conflict. In scenarios like this, who should provide the KHRplatform.h header. Some users, may want use exclusively EGL/GLES2 binaries, and they dont need GL support. How can we resolve this conflict? Thanks Mads (In reply to Madhurkiran from comment #2) > Hi all, > > I see that certain GL headers like "glcorearb.h" needs "KHRplatform.h" > header files. This works seamlessly when the GL and EGL providers are MESA. > In scenarios where the GL provider is MESA and EGL provider is some GPU > vendor say ARM, in that scenario, the khrplatform header comes from two > different providers and that results in conflict. In scenarios like this, > who should provide the KHRplatform.h header. Some users, may want use > exclusively EGL/GLES2 binaries, and they dont need GL support. How can we > resolve this conflict? > > Thanks > Mads Hi! Please open a new issue when you encounter a new issue, it helps keep things clearer ;) As for your issue, I'm afraid if a user chooses to pull two khrplatform.h from two different providers, the user is the one who has to choose which one to keep, or how to merge/combine them. Neither provider can decide "I'm more important than any other provider, keep me!" Hopefully though, this should be easy enough for the user to choose: keep the most recent one (see the date at the top of the file), and if the other one was modified from what Khronos provides then copy those modifications :) |
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.
Since commit f7d42ee7d3 (include: update GL & GLES headers (v2), 2018-07-18) the 'KHR/khrplatform.h' header is included by 'GL/glcorearb.h' and 'GL/glext.h' but 'configure.ac' still says AM_CONDITIONAL(NEED_KHRPLATFORM, test "x$enable_egl" = xyes -o \ "x$enable_gles1" = xyes -o \ "x$enable_gles2" = xyes) Therefore configuring with all three of those disabled: ./autogen.sh \ --prefix="$prefix" \ --enable-debug \ --disable-dri \ --disable-egl \ --disable-gbm \ --disable-gles1 \ --disable-gles2 \ --disable-shared-glapi \ --with-platforms=x11 \ --enable-glx=gallium-xlib \ --enable-gallium-osmesa \ --with-gallium-drivers=swrast \ --enable-gallium-llvm=yes \ LLVM_CONFIG=$llvm_config \ --enable-llvm-shared-libs \ creates an installation that gives preprocessing errors to clients: /.../include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory