[bitbake-devel] [OE-core] Two recipes providing the same .so... How it should not be done :)

[Ricardo Ribalda Delgado]

HI Ross
On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross <ross.burton at intel.com> wrote:
>
> Does they literally just provide a libgl.so and no headers, etc?

It provides:

/usr/lib/libGL.so.1.2.0
/usr/lib/libGL.so.1


>
> Ross
>
> On Fri, 1 Mar 2019 at 11:29, Ricardo Ribalda Delgado
> <ricardo.ribalda at gmail.com> wrote:
> >
> > Hello
> >
> > I have a build system that supports some aarch64 machines. For most of
> > the them, the only difference is the kernel configuration, kernel
> > version.
> >
> > I am using multiconfig on my build server and the build goes really
> > fast thanks to all the shared binaries/artifacts.
> >
> > But I have a problem adding a new machine. This machine is also
> > aarch64, with a special kernel (nothing new here), but in this case
> > the vendor provides a binary .so for libgl that is required to get
> > hardware acceleation.
> >
> > I could .bbappend mesa and on the installation part replace libgl with
> > the new .so. But then everything that depends on mesa needs to be
> > rebuilt for that machine and I could not use multiconfig.
> >
> > Instead I have created a new recipe: mesa-gl-replace.bb that has the
> > file. This breakes completely the design of OE, but works.
> >
> > Some snipsets of the "magic" to make it work:
> >
> > #Force that the version is allways higher than the one from mesa:
> > PE = "5"
> >
> > #Rprovide the same as mesa
> > RPROVIDES_libgl-mesa += "libgl"
> >
> > #Do not overwrite pkgdata of mesa
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> >
> > #Keep this on machine
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > #Make sure we are not saved as providers for libgl
> > PRIVATE_LIBS = "libGL.so.1"
> >
> > #Avoid sanity checks
> > read_subpackage_metadata () {
> > }
> >
> >
> > If your eyes have not fallen as this point, this means you have a lot
> > of tolerance for crappy code, congrats :)
> >
> > Now the question. Is there a better way to do this?
> >
> > PS: I already tried and failed with update_alternatives
> >
> >
> > Best regards!
> >
> >
> > --
> > Ricardo Ribalda
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda