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?
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
