Bug 107511 - KHR/khrplatform.h not always installed when needed
Summary: KHR/khrplatform.h not always installed when needed
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: All All
: medium blocker
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-07 11:43 UTC by Brad King
Modified: 2019-05-08 07:06 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brad King 2018-08-07 11:43:27 UTC
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
Comment 1 Eric Engestrom 2018-08-07 13:49:32 UTC
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
Comment 2 Madhurkiran 2019-05-07 21:17:11 UTC
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
Comment 3 Eric Engestrom 2019-05-08 07:06:20 UTC
(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.