[OE-core] [PATCH 3/3] libepoxy: Upgrade 1.4.2 -> 1.4.3

[Khem Raj]

On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera <gizero at gmail.com> wrote:
>
>
> Il 11 lug 2017 8:00 PM, "Khem Raj" <raj.khem at gmail.com> ha scritto:
>
> On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen
> <jussi.kukkonen at intel.com> wrote:
>> On 11 July 2017 at 11:27, Jussi Kukkonen <jussi.kukkonen at intel.com> wrote:
>>>
>>> On 11 July 2017 at 10:42, Jussi Kukkonen <jussi.kukkonen at intel.com>
>>> wrote:
>>>>>
>>>>> Exception: FileExistsError: [Errno 17] File exists:
>>>>>
>>>>> '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/sysroots-components/raspberrypi3/userland/usr/include/KHR/khrplatform.h'
>>>>> ->
>>>>>
>>>>> '/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/gtk+3/3.22.16-r0/recipe-sysroot/usr/include/KHR/khrplatform.h'
>>>>
>>>>
>>>> /usr/include/KHR/khrplatform.h is the egl platform header file, provided
>>>> by both mesa and RPI userland. Does mesa end up in your gtk+3
>>>> recipe-sysroot
>>>> somehow?
>>>>
>>>> For clarity: this could be a bug but it is unlikely to be related to the
>>>> libepoxy change (it does not use or ship the actual header file).
>>>>
>>>
>>>
>>> Actually this was maybe fixed by Otavios upgrade to mesa 17.1.4 -- mesa
>>> accidentally shipped khrplatform.h even when egl was disabled (which is
>>> what
>>> mesa-gl in oe-core does).
>>>
>>
>> Sorry, I've not had enough  coffee. It was the other way round:
>> khrplatform.h is the platform header that mesa now thinks is needed
>> whether
>> egl is enabled or not -- so they've started installing it in any case from
>> 17.1.4 which means mesa-gl now provides khrplatform.h and thus conflicts
>> with userland.
>>
>> I don't know what the correct fix is yet, just wanted to correct my
>> original
>> wrong info.
>>
>
> Post an update to sync this header for userland package.
>
>
> Will this help solving the gtk+3 issue of mesa-gl and userland now both
> providing the same header and causing recipe-sysroot construction to fail?

No it certainly would not. But we can then decide who provides it, in
a easy way.