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