On Tue, Jul 11, 2017 at 9:56 PM, Andrea Galbusera <giz...@gmail.com> wrote: > On Wed, Jul 12, 2017 at 12:38 AM, Khem Raj <raj.k...@gmail.com> wrote: >> >> On Tue, Jul 11, 2017 at 3:02 PM, Andrea Galbusera <giz...@gmail.com> >> wrote: >> > >> > >> > Il 11 lug 2017 8:00 PM, "Khem Raj" <raj.k...@gmail.com> ha scritto: >> > >> > On Tue, Jul 11, 2017 at 1:34 AM, Jussi Kukkonen >> > <jussi.kukko...@intel.com> wrote: >> >> On 11 July 2017 at 11:27, Jussi Kukkonen <jussi.kukko...@intel.com> >> >> wrote: >> >>> >> >>> On 11 July 2017 at 10:42, Jussi Kukkonen <jussi.kukko...@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?
Firstly, determine where this file belongs to. If it is part of egl/gles then it should go to userland, otherwise it should be provided by mesa when using userland for graphics -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
