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

[Andrea Galbusera]

On Wed, Jul 12, 2017 at 12:38 AM, Khem Raj <raj.khem at gmail.com> wrote:

> 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.
>

I may be in the need to craft something locally to unbreak building with
current master... Could you please shed some light on how this should be
done then? Is this a matter of completely removing either mesa-gl or
userland from gtk+3 deps or a more selective change to avoid the clash in
recipe-sysroot?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170712/06a3361e/attachment-0002.html>