On Wed, Jul 12, 2017 at 7:11 AM, Khem Raj <raj.k...@gmail.com> wrote:
> 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 > If I understand correctly your point, you mean it is about having the two upstream agreeing on where the header belongs to and fixing either one or the other to stop providing it. In the meanwhile, from an oe perspective, having such a patch in place for any of the two or even removing the file in an appropriate do_install_append should do the job, right?
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
