On Thu, Apr 20, 2017 at 12:26 AM, Trevor Woerner <twoer...@gmail.com> wrote: > I'm trying to build a certain combination of software for a given SoC. mesa > (meta-gl, specifically) provides a libgbm, but if you don't want to use mesa's > libgbm you can disable it with a PACKAGECONFIG. I.e. > > PACKAGECONFIG_remove_pn-mesa-gl = "gbm" > > It works, and looking at the packages-split I can verify that nothing gets > installed for either mesa's libgbm nor libgbm-dev. > > This particular SoC's BSP, however, provides an SoC-specific libgbm that > should be used in place of mesa's. This is easy, set the PREFERRED_PROVIDER, > tell mesa you don't want its gbm and everything is good, right? > > :-( > > The build fails because the *packagedata* from both mesa-gl and this SoC's > specific libgbm collide. The packagedata, I guess, states what *might* be > installed. So since both packages might install /usr/lib/libgbm, the build > freaks out: > > ERROR: mesa-gl-2_17.0.2-r0 do_packagedata_setscene: The recipe > mesa-gl is trying to install files into a shared area when those files > already exist. Those files and their manifest location are: > > /z/build-master/bbb/build/tmp-glibc/pkgdata/beaglebone/runtime/libgbm-dev > (matched in manifest-beaglebone-libgbm.packagedata) > > /z/build-master/bbb/build/tmp-glibc/pkgdata/beaglebone/runtime/libgbm > (matched in manifest-beaglebone-libgbm.packagedata) > Please verify which recipe should provide the above files. >
mesa-gl is a separate recipe, if its providing more than gbm and that extra stuff is needed too in your package thats when you might run into these kind of issues. I would suggest to divide mesa-gl further into more granular recipes. > This is very annoying because, even if hell froze over and somehow both libgbm > and mesa-gl installed both of their libgbm packages, there would actually only > be one provider since mesa-gl's libgbm package is, in fact, empty. > > Is there a way to get this to work? I can't not build mesa-gl, because I need > some of its parts (virtual/mesa, virtual/libgl) and I can't not use the SoC's > libgbm because (I'm guessing) that's what I'm supposed to use. > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto